Re: MT Design Question
On Aug 29, 8:40 am, "Balog Pal" <p...@lib.hu> wrote:
"Joshua Maurice" <joshuamaur...@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,
Actually, pthread has an almost workable model of thread cancel.
Where as thread cancel under Windows is broken.
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
;-)
Depending on what you are trying to do, you need different
tools. Globally speaking, pthread comes closer to being
complete than Windows, but there are a large number of
applications which can effectively be written under either.
(Note too that Windows 7 does have conditional variables.)
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.
If what you're trying to do is increment, then the atomic
increment functions of Windows are great. An atomic compare and
swap is, of course, sufficient for everything; it's the low
level concept used to implement conditions (just as, in many
cases, conditions are the low level concept used to implement
message queues).
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.
It depends on the high-level use case. Although with an atomic
compare and swap, you can implement condition variables without
too much difficulty. It's just additional work for you.
--
James Kanze