[Webkit-unassigned] [Bug 16596] ThreadSafeShared should be lock-free where possible

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 24 13:47:57 PST 2007


http://bugs.webkit.org/show_bug.cgi?id=16596





------- Comment #3 from mrowe at apple.com  2007-12-24 13:47 PDT -------
(In reply to comment #2)
> (From update of attachment 18091 [edit])
> +#if COMPILER(MSVC)
> +#include <windows.h>
> +#endif
> 
> I think (though I'm not quite sure) that we avoid including windows.h in
> headers to reduce conflicts.
> 
> Also, why is the check for COMPILER(MSVC), not PLATFORM(WIN_OS) or
> PLATFORM(WIN)?

I guess PLATFORM(WN) may be more appropriate.  I don't see how I can avoid
including windows.h here given that the header file uses a function it
declares.

> 
> +inline void InterlockedIncrement(int volatile* addend)
> +{
> +#if PLATFORM(X86) || PLATFORM(X86_64)
> +    __asm__(
> +        "lock\n\t"
> 
> FWIW, OS X also has atomic functions, e.g. AddAtomic and DecrementAtomic. I'm
> not sure if these are better or even suitable, but since you use an OS-provided
> function on Windows, there should at least be a comment explaining why we don't
> do the same on the Mac.

Two reasons I didn't use them: 1) They won't be inlined quite as nicely like
these implementations are due to them consisting of a function call, 2) These
work on non-Mac platforms.   The Win32 version will use a compiler intrinsic if
it's available which will be inlined, and that avoids having to write a second
version of the x86 code in MSVC-friendly form.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list