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.

On Sun, Apr 20, 2008 at 9:09 AM, Kimon Hoffmann <Kimon.Hoffmann@rapidsolution.de> wrote:
Hi Anthony,


Anthony Williams wrote:
Quoting Anteru <newsgroups@catchall.shelter13.net>:
>>
Well, I still have problems with the conditions, even with the latest
SVN.

Yes, the win32 spurious-wake-prevention code is faulty. The one-line  fix I originally suggested is better in that it does actually work, at  the expense of more spurious wakes.

I'm working on a new spurious-wake-prevention mechanism. I'm really  frustrated that this hasn't come to light until now.

Just FYI, last Thursday we encountered a similar/the same problem with the new threading code and filed a Trac ticket. The ticket number is #1834.
For now we have resorted to switching back to Boost 1.34.1 but since Boost 1.35.0 includes a few important fixes to other libraries it would be really great if a fix for this would make it into 1.35.1.

One question about the spurious-wake-prevention: Is the absence of spurious wakes one of the guarantees made by the threading library proposal?

Best regards,
 Kimon



_______________________________________________
threads-devel mailing list
threads-devel@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/threads-devel