Question

I’m using TinyThread++ to get clean and simple platform independent control over threading features in my project. I just came upon a situation where I’d like to have responsive synchronized message passing without pegging the CPU, while allowing a thread to continue to do a bit of work on the side while it is idle. Sure, I could simply spawn a third thread to do this “other work” but all I’m missing is a condition variable wait(int ms) type function rather than the wait() that already works great. The idea is that I’d like for it to block only for up to ms milliseconds, so it will be able to time out and perform some actions periodically (during which the thread will not be actively waiting on the condition variable). The idea is that even though it’s nice to have the thread sitting there waiting to pounce on any incoming messages, if I give it some task to do on the side which takes only 50 microseconds to execute, and I only need to run that once every second, it definitely shouldn’t push me to make yet another thread (and message queue and other resources) to get it done.

Does any of this make sense? I’m looking for suggestions on how i might go about implementing this. I’m hoping adding a couple of lines to the TinyThread code can provide me with this functionality.

Answer 1

Well the source code for the wait function isn’t very complicated so making the required modificiations looks simple enough:

• The linux implementation relies on the pthread_cond_wait function
  which can trivially be changed to the pthread_cond_timedwait
  function. Do read the documentation carefully in case I forgot about any minutias.

• On the windows side of things, it’s a little more
  complicated and I’m no expert on multithreading on windows. That
  being said, if there’s a timed version of the _wait function (I’m pretty sure there is),
  changing that should work just fine. Again, read over the documentation carefully before doing any modifications.

Now before you go off and do these modifications, I don’t think what you’re trying to do is a good idea. The main advantage of using threads is to conceptually seperate different tasks. Trying to do multiple things in a single thread is a bit like trying to do multiple things in a single function: it complicates the design and makes things harder to debug. So unless the overhead of creating a new thread is provably too great or unless the resulting code remains simple and easy to understand, I’d split it up into multiple threads.

Finally, I get the feeling that you might not be aware that condition variables can return spuriously (returns without anybody having done any signalling or returns when the condition is still false). So just in case, I’d suggest reviewing the usage examples and making sure you understand why those loops are there.