Finally doing some pthread stuff

For years and years, I've staid away from multi-threaded programming. Not that I dislike threads per se: I once made a multi-threaded micro-kernel myself after I spent countless hours studying IA32 Task State Segments. But who needs threads when you have two ARM cores, hardware interrupts for driving your sound DSPs and proper multi-layers video chip anyway ?

Even for network / system programming, I tend to prefer use pipes or socketpairs over threaded stuff. They strace better. You can actually see the flow of acknowledgements between entities. For most things, this is preferable over raw performance.

But a couple of years ago, I've been thrown in a pool where threads are already there and I need to swim with them. Parts of the pool use boost abstractions and are usually not too hard to work with because my colleagues did a great job at building robust RIAA things around those abstractions. But other parts of the pool use plain pthread + plain Windows thread/event/locks API. And as you can guess, upgrading corporate project to use C++11 threads is usually not easy (not that I know these any better, though).

One function that is used a lot in that code is pthread_cond_timedwait(). And there are a few things you must not do with that:

• do not call it if you're not holding the mutex argument
• a corresponding pthread_cond_signal is lost (not buffered) if no one is waiting on the condition at the moment of cond_signal

When debugging

• you may need set non-stop on to prevent some other thread from interfering (e.g. declaring things timed out) while you're stepping through some thread-of-interest.
   

(more to come)