Re: [Threads-devel] More problems with condition

From: Anthony Williams (anthony_at_[hidden])
Date: 2008-04-21 03:26:15

Quoting Patrick Twohig <p-twohig_at_[hidden]>:

> I've read doug Schmidt's paper a little while back when I was trying to
> implemented a condition variable on a system lacking support for it.
> Additionally, SignalObjectAndWait was not available because the code used
> CriticalSections instead of Windows Mutexes so I ended up  basing the
> implementation on some code I found which used a deque of signals to notify
> one or all threads.  I don't know if that approach introduces fairness
> problems or not, but it seemed to work for me.  I'm certainly not suggesting
> tearing apart all the code in boost::condition_variable with something
> similar, but I was just more comparing boost's implementation with with a
> different implementation I had found.

There's lots of ways of implementing condition variables. One of my  
earlier prototypes was like that. It's essentially a LIFO or FIFO  
scheduler. The issue here is that the OS scheduler doesn't control the  
wake order, so high priority threads might lose out to low priority  
ones.

If I can't fix the current problems in a sensible manner, I might  
revert to that prototype, or I might revert to the old  
boost::condition algorithm. The reason I changed from the old  
algorithm is that a notify has to wait until the notified thread has  
woken before it can resume. This might result in a high-priority  
thread waiting on a low priority thread.

Anthony
-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL