Re: [Boost-users] [Boost.Thread] Scheduling

From: Zeljko Vrba (zvrba_at_[hidden])
Date: 2008-08-11 10:42:53

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_lock<boost::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.