The atomic operations while nice are basically useless without memory visibility rules or semantics. This is something that get discussed a lot on comp.programming.threads. I suppose you can assume they are there but that's assuming a lot.
Also, doing condvars on windows isn't that easy as Douglas Schmidt writes up here [wustl.edu].
Writing portable thread libraries seems to be a popular activity. It would be nice if the authors of those packages documented that they were aware of the issues as a first step in convi
For the atomic operations, the intel based code is ok since the lock prefix serializes memory. The powerpc load reserved / store conditional do not however and explicit memory barriers are required and they are not there. That's bad.
For the win32 version of condvar, I don't think a win32 Event isn't going to hack it. The current logic allows a condvar to remain signaled until the all waiters have woken up and have decremented the use count to zero. This could lead to a lot of spurious wakeups if some
Multi-threading isn't that simple (Score:5, Interesting)
Also, doing condvars on windows isn't that easy as Douglas Schmidt writes up here [wustl.edu].
Writing portable thread libraries seems to be a popular activity. It would be nice if the authors of those packages documented that they were aware of the issues as a first step in convi
Follow up - I took a quick look at the source. (Score:5, Insightful)
For the win32 version of condvar, I don't think a win32 Event isn't going to hack it. The current logic allows a condvar to remain signaled until the all waiters have woken up and have decremented the use count to zero. This could lead to a lot of spurious wakeups if some
Re:Follow up - I took a quick look at the source. (Score:2)
Dropping a link to Schmidt's work in there might not be a bad means of stealth education, either.