Re: MT Design Question
"Joshua Maurice" <joshuamaurice@gmail.com>
This is sort of a pet peeve of mine, but please don't suggest to
anyone to actually directly use the windows threading API if at all
possible. It's borked, at least for windows XP and earlier, as it
lacks condition variables.
Wow. on the same logic the pthread API is even more "broken" as it does not
have interlocked atomic ops, thread cancel, waitformultipleobject, just from
top of my head... For some reason I could prtty well solve all my MT
problems using events and interlocked*. I'd say it is more like boroen
logic ;-)
When working at the level of mutexes or
semaphores (and not hardware memory barriers or lock free algorithms),
you really need the "primitive" "release mutex and wait on a signal"
aka pthread_cond_wait in order to do sane threading programming at the
mutex or semaphore level.
Guess you needed them so much to work around the lack of interlocked
increment and interlocked compare&swap. Having those atopmics remove many
cases where you need to lock a mutex.
Implementing the equivalent of
pthread_cond_wait with the windows XP and earlier API is surprisingly
difficult, and generally results in much less efficient code than if
they had properly implemented kernel and scheduler to directly
understand pthread_cond_wait or equivalent.
Implementing the perfect equivalent maybe. But covering the same high-level
use case is not. The use of attached an auto-locking mutex in signaling
looks convenient, but is not needed more often than it is. And the rest of
the cases can be probably covered better too, using WaitFormultipleObjects.
(Btw if you just use the latter to wait on Event and a mutex with ALL
option, isn't the effect the same as you are after? )