Re: gthread-win32.c

[Steven Brooks <umbrook0 cs umanitoba ca>]

Dan Maas wrote:

> > > 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...


My suspicion is you need a thread to manage the other threads.  It uses
suspends and resumes to control them, and all event requests go through
the management thread.  Definitely do-able, and as long as all event
requests (Set, Reset and Pulse) go through the thread, you can guarantee
correct semantics.

To guarantee cond_wait, you probably have to pipe the mutex requests
through that thread as well.


> > 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.


Didn't know that.


> 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...


You're absolutely right.  But I suspect by the time we implement full
POSIX semantics on Windows, we might as well just keep using a proper
pthreads-on-windows library.

In that case, as long as the trouble areas in the Win32-native
implementation are documented, I don't see the problem with
``close-enough'' solutions.

Obviously, the ``close-enough'' should be the best possible without
basically implementing a pthread library, but I don't think it needs to
be exact.

Alternatively, the Win32-native implementation does what it can,
safely, and asserts on the rest; for example, it would implement
cond_wait if it detects it is running on NT, but would assert if it
detects it is running on 9x.

Although, it would be a shame to not implement ``wake all threads
waiting for event'' even though a quick set of n pulses would probably
work in practice.

Steven