On Mon, 2005-03-21 at 11:07 -0500, Gottlob Frege wrote:
So, it doesn't seem to be getting any easier! *Almost* to the point
where a big named mutex becomes tempting - there is a lot to be said
for simplicity. However, my/the goal is still to at least minimize
the non-contention simple init case...
I'm less and less tempted to use a named mutex. Perhaps there's a
standard technique, but AFAICS it's impossible to guarantee that the
name is unique across the system (and all Windows variants).
And I agree, minimum overhead for the uncontended case is the top
priority (after correct behaviour). I'm not concerned at all about speed
in the cancellation case.
And the event is still an auto-reset, although I no longer think it
really matters - I really haven't had the tenacity to think this stuff
through. If it doesn't matter, manual-reset would be better, I think
- I don't like having 1 thread relying on another thread waking it up,
- for cases where the thread is killed, or strange thread priorities,
etc.
It all looks to me like it will work. I don't recall, in the version
that's in pthreads-win32 now, why I included eventUsers (++/--) in what
you have as the __lock() sections. Maybe to save additional Atomic calls
(bus locks). But now I realise [in that version - not yours] that waking
threads can block unnecessarily when leaving the wait section.
It probably doesn't matter if cancel_event is auto or manual. I think
there will be at most one thread waiting on it. And, for 'event', like
you I'm uncomfortable with daisy-chaining SetEvent() calls.
The only problem with the alternative of using a manual-reset event is
that some thread/s may busy-loop for a bit until an explicit reset
occurs. It seems untidy, but it's probably more robust than daisy-
chained SetEvents given the issues you've identified above.
So I'm tempted to leave both events as manual-reset events. I'm also
guessing that this busy-looping will be extremely rare - perhaps only
when a new thread sneaks in to become initter, then suspends just inside
while the first waiter is waking and heading back to the loop start.
I'll run your design and let you know the results.
Thanks.
Ross