Re: gthread-win32.c

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

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]