Re: gthread-win32.c

["Dan Maas" <dmaas dcine com>]

> > static void
> > g_cond_broadcast_win32_impl (GCond * cond)
> > {
> >   /* XXX : signal all waiters ? */
> > }
>
> No way (that I know of) to do this in windows.  At least, not through
> the Win32 API.  An event created to auto-reset will always signal
> exactly one thread. An event created to manual-reset will always signal
> all threads.

AFAIK it is actually possible to accomplish both wake-one and wake-all on
Windows, but writing a correct implementation with no race conditions is
*not* trivial and involves some overhead. I believe the Cygnus Win32
pthreads DLL does have a correct implementation, you may want to check their
sources...

> In POSIX threads, the combination of releasing a mutex, waiting for an
> event and relocking the mutex can be done in two atomic steps:
> 1. release a mutex
> 2. wait on an event and relock the mutex
>
> Probably, a ReleaseMutex followed by a WaitForMultipleObjects (set to
> wait for all objects, and not just whichever one signals first) would
> have the same or close-enough semantics.

Windows NT provides the atomic SignalObjectAndWait() specifically for this
purpose.

On Windows 98, SignalObjectAndWait() is NOT available, so there is NO way to
implement POSIX-style condition variables without risking a lost wakeup
between the mutex release and the WaitForMultipleObjects(). (I'm not sure
what the current situation with Win2k/WinME is....)

In any case, I think there needs to be a policy regarding possibly racy
implementations... It would be easier just to let these slide, but keep in
mind that you may get random and difficult-to-replicate deadlocks in
threaded apps...

Regards,
Dan