On Fri, 19 Nov 2004 15:35:44 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer wrote:
> > Win32 doesn't require anything else, but I don't think I like this
> > idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what
> > happens when some code goes to LOCK(m)? It would work under POSIX but
> > break under Win32.
>
> The mutex in COND_INIT is specific to that condition, it can't get
> reused in unrelated places. But it is used to synchronize {push,pop,
> wait_for}_entry. How is e.g. tsq.c:push_entry() synchronized then on Win32?
Actually, that part works in Win32. Since the queue uses the mutex for
synchronizing access to the queue, it doesn't matter that Win32
wouldn't need it for the condition var.
The problem would only occur when the condition variable doesn't have
anything that it's guarding access to. For example, a thread might be
waiting for a timer to fire. This thread would wait on a condition
variable that would be signalled by the timer thread. Under POSIX, the
newly awoken thread would own a mutex which it wouldn't really need
for anything.
I think that maybe what we need is a MUTEX, a CONDITION, and a
QUEUE_CONDITION. The QUEUE_CONDITION would always contain a mutex and
a condition, while the CONDITION would have a c,m for POSIX and just c
for Win32.
Also, note that with Win32 conditions you must indicate at creation
time whether you want to Signal or Broadcast. Emulating POSIX
semantics on Win32 are tricky, and it's probably overkill for these
purposes.
GNS
