improving threading / osl::Condition abstraction ...

[Michael Meeks]

Hi there,

	I was writing a thread-pool class the other day - against the clock cf.
master's sc/source/filter/oox/threadpool.* - and it was interesting to
become a victim of the apparently well known lost wakeup issue that our
approach to osl::Conditions creates.

	I propose the following patch to osl::Condition:

diff --git a/include/osl/conditn.hxx b/include/osl/conditn.hxx
index 5ca0323..33a0fcc 100644
--- a/include/osl/conditn.hxx
+++ b/include/osl/conditn.hxx
@@ -29,7 +29,13 @@
 
 namespace osl
 {
-
+    /**
+     * Warning: the Condition abstraction is inadequate for any
+     * situation where there may be multiple threads waiting on
+     * the same condition. It can only be used to synchronise
+     * interactions between two threads cf. lost wakeups in:
+     *    http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
+     */
     class Condition
     {
     public:


	Until we fix it.

	The real question is: should we fix it in-place - by deprecating the
'set' and 'reset' methods; and adding the familiar: 'signal' 'broadcast'
and a wait( Mutex &rMutex ) - method - preferably implemented on Windows
using Norbert's abstraction:

	https://gerrit.libreoffice.org/6837

	or something similar / better.

	Or - should we deprecate it and use something else (boost?) wherever
possible with an easy [sic] hack to replace our threading code with
that ?

	The basic problem is; and I quote the above win32-cv-1.html link:

	"The lack of condition variables in Win32 makes it
	 harder to implement certain concurrency abstractions, such
	 as thread-safe message queues and thread pools."

	To which I can only say "Amen" - the existing API makes every instance
of threading I add a spectacularly horribly nervous exercise in
considering un-necessary interleavings between Mutexes and Conditions
that should not have to be.

	As we start to move carefully selected pieces of the code-base to use
threading to take advantage of all that unused silicon doing not much on
our machines - it would be great to improve the helpers so that we get a
better result =)

	Thoughts much appreciated,

	ATB,

		Michael.

PS. Stephan - any chance you can reply-to-All ? ;-)
-- 
 michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot