On Mon, Aug 11, 2008 at 02:01:46PM +0200, Ruediger Berlich wrote:
The threads increment a variable. Once this variable has reached a threshold (here: 10), execution is supposed to stop. This is done by calling the interrupt() function on each thread, which in turn catch the corresponding exception and act on it.
All this seems to work nicely, except for the fact that the "master thread" (thread4 in this example) does not seem to get any processing time over a long period. Hence thread 1,2 and 3 count to a very high number before the stop condition is met.
Threads are by their very nature non-deterministic. If you want deterministic behavior, i.e., behavior that is independent of scheduling order and relative speeds of threads, you have to code it yourself by using appropriate mechanisms.
Is there anything that can be done to improve the time slices allocated to thread4 ? I am already calling the yield() function in thread1, 2 and 3.
Friendly advice: get a good book on multi-threaded programming before proceeding with your project. Answer to your question: look up the sched_setscheduler function. Assign SCHED_RR policy and equal priorities to all threads. You need to be root to do be able to do that. (Or use some fine-grained capability mechanism.. Solaris has one, dunno about linux... found it; give your user CAP_SYS_NICE privilege.)
boost::unique_lockboost::mutex lock(helloMutex_); go_=true; lock.unlock(); readyToGo_.notify_all();
The condition variable should be signaled _before_ the lock is unlocked, otherwise you have a race condition upon which causes the signal to get lost.