Re: [MinGW-dvlpr] Fw:[Mingw-users]InterlockedCompareExchange(Was:no subject)

[Wu Y. <ad...@ne...>]

I do not think so.  As I previously mentioned, currently one needs to
use the "lock" prefix in inline assembly to ensure correctness on SMP
systems, but the system routines can detect the CPUs and do not use
"lock" unnecessarily.  The result is that using inline assembly for the
lock primitives is slower than the system routines on uniprocessor
systems.

As Danny suggests, we can detect the CPU status on load time, set a
mark, and run the routines with or without "lock" accordingly.  However,
it is a little complicated, and the only advantage I can see is that we
can support the Interlocked... routines correctly and efficiently on
Windows 95.  Although I should not break it, I do not see it my duty to
improve an obsoleted OS.

Best regards,

Yongwei

On Thu, 2004-05-27 at 12:03, Aaron W. LaFramboise wrote:
> Since inline asm is now being used to acquire the lock when it is not 
> contended on the modern IA32 processors, does anyone think it would be 
> reasonable to remove all of the ifdef's and __GTHREAD_HIDE_WIN32API, and 
> no longer include <windows.h> in gthr-win32.h in any case?
> 
> In particular, I am proposing that the only inline code with respect to 
> the mutexes that would be in gthr-win32.h would be the inline assembler 
> that attempts to acquire and release the lock in the non-contended 
> case.  If the the quick attempt to grab a lock failed, control would 
> pass to a function in gthr-win32.c which would then call 
> WaitForSingleObject.  Targets for which inline assembler don't have any 
> inlined code at all, and call directly to gthr-win32.c.  I do not think 
> this would decrease performance for the targets with inline assembler 
> available as the cost of WaitForSingleObject and the likely context 
> switches will dominate over the cost of not being inlined.
> 
> This still leaves Objective C, TLS, and gthread_once that require 
> windows.h in gthr-win32.h.  I don't know anything about Objective C, but 
> perhaps it can/should use gthread_mutex like everything else.  I don't 
> think either TLS (with the possible exception of getspecific()) or 
> gthread_once get any reasonable performance advantage from being in 
> headers, and perhaps they might be better suited to being in gthr-win32.c.
> 
> Possible of advantages of this:
> -It might improve performance in some cases because less code would need 
> to be inlined (only an atomic instr and test/branch)
> -It might decrease code/executable size slightly in some cases for the 
> same reason.
> -The number of possible code variations due to macros in the mutex code 
> for each target would decrease to one, which might minimize future 
> maintenance problems or ABI concerns.
> -No longer any need to have to worry about the issues regarding 
> including <windows.h> (at least with regards to gthr) and the problems 
> it might cause now or in the future.
> 
> This would be an ABI change versus what is presently proposed, so if 
> anyone thinks this is a good idea, now would be the time to do it.
> 
> Aaron W. LaFramboise