[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