On Thu, 2004-05-20 at 05:06, Thomas Pfaff wrote:
> Wu Yongwei wrote:
> > On Wed, 2004-05-19 at 04:31, Aaron W. LaFramboise wrote:
> >>Wu Yongwei wrote:
> >>>When all threads are using __gthr_win32_mutex_trylock, it works.
> >>>However, when some threads use __gthr_win32_mutex_lock and others use
> >>>__gthr_win32_mutex_trylock, problems will still occur. And I wonder
> >>>whether it will scale well when there are many mutexes.
> >>Pardon my ignorance, but what is __gthr_win32_mutex used for? Exception
> >>handling, anything else? Are they ever intended to be held for more
> >>than a short period of time? Is there any particular reason normal
> >>spinlocks can't be used? Spinlocks can be relatively safe on Windows
> >>compared to other operating systems, and are almost certainly going to
> >>be faster than any other synchronization primative. This also avoids
> >>possibly far-fetched strange problems involving inability to allocate or
> >>manipulate a mutex, avoiding those suspicious almost-never-used error
> >>control paths.
> > AFAIK, __gthr_mutex_... are required interfaces in order to support the
> > concept of a cross-platform mutex. Libstdc++-v3 uses it to synchronize
> > memory accesses. The idea is good, but the requirement of an unused
> > __gthr_mutex_trylock is really a headache on Win32: Merely because of
> > its existence (although it is not really used in GCC), Danny used Win32
> > MUTEXs instead of CRITICAL_SECTIONs to implement __gthr_mutex_...
> > interfaces in order to work around the lack of TryEnterCriticalSection
> > on Win9x platforms. My patch used a customized mutex implementation to
> > accelerate the lock/unlock operations, but was not careful enough to
> > make it work on Windows 95 boxes.
> > Danny, I searched online and found that the system requirements for
> > Windows 98 were 486DX/66MHz. So I doubt the possibility of implementing
> > InterlockedCompareExchange on an i386 CPU.
> Just to add my 2 cents here.
> The new mutex implementation needs an xadd based
> InterlockedIncrement/Decrement too, otherwise you can not test reliable
> for a return value other than 0.
> To keep W95 running i vote for inline assembler versions of
> InterlockedIncrement/Decrement and CompareExchange based on xadd and
> cmpxchg. Better drop i386 than W95.
Thomas, I had already "re-invented the wheel" (written all the three
functions in inline assembly so that I need not worry about licensing
issues on this matter ever more) and finished the new patch based on
them, but at last gave up, because they have worse performance than the
system routines on uniprocessor systems. I guess the reason is that I
have to use "lock" to ensure correctness on all systems, but the OS can
know it is a uniprocessor system and use routines without "lock".
So I adopted Aaron's opinion (thanks, Aaron) and used -1 as the initial
counter value. The patch is attached for your review here. Danny, if
you do not see any problems, I shall post it to gcc-patches.