New design for pthread_once (with cancelability); ABI change

1 files changed, 57 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index 4cb2469..ceb14fa 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,60 @@
+2005-03-13  Ross Johnson  <rpj at callisto.canberra.edu.au>
+
+	* pthread_once.c (pthread_once): Completely redesigned; a change was
+	required to the ABI (pthread_once_t_), and resulting in a version
+	compatibility index increment.
+
+	NOTES:
+	The design (based on pseudo code contributed by Gottlob Frege) avoids
+	creating a kernel object if there is no contention. See URL for details:-
+	http://sources.redhat.com/ml/pthreads-win32/2005/msg00029.html
+	This uses late initialisation similar to the technique already used for
+	pthreads-win32 mutexes and semaphores (from Alexander Terekhov).
+
+	The subsequent cancelation cleanup additions (by rpj) could not be implemented
+	without sacrificing some of the efficiency in Gottlob's design. In particular,
+	although each once_control uses it's own event to block on, a global CS is
+	required to manage it - since the event must be either re-usable or
+	re-creatable under cancelation. This is not needed in the non-cancelable
+	design because it is able to mark the event as closed (forever).
+
+	When uncontested, a CS operation is equivalent to an Interlocked operation
+	in speed. So, in the final design with cancelability, an uncontested
+	once_control operation involves a minimum of five interlocked operations
+	(including the LeaveCS operation).
+	
+	ALTERNATIVES:
+	An alternative design from Alexander Terekhov proposed using a named mutex,
+	as sketched below:-
+
+	  if (!once_control) { // May be in TLS
+	    named_mutex::guard guard(&once_control2);
+	      if (!once_control2) {
+	         <init>
+	         once_control2 = true;
+	      }
+	    once_control = true;
+	  }
+	
+	A more detailed description of this can be found here:-
+	http://groups.yahoo.com/group/boost/message/15442
+
+	[Although the definition of a suitable PTHREAD_ONCE_INIT precludes use of the
+	TLS located flag, this is not critical.]
+	
+	There are three primary concerns though:-
+	1) The [named] mutex is 'created' even in the uncontended case.
+	2) A system wide unique name must be generated.
+	3) Win32 mutexes are VERY slow even in the uncontended 	case. An uncontested
+	Win32 mutex lock operation can be 50 (or more) times slower than an
+	uncontested EnterCS operation.
+
+	Ultimately, the named mutex trick is making use of the global locks maintained
+	by the kernel.
+
+	* pthread.h (pthread_once_t_): One flag and an event HANDLE added.
+	(PTHREAD_ONCE_INIT): Additional values included.
+
 2005-03-08  Ross Johnson  <rpj at callisto.canberra.edu.au>

 
 	* pthread_once.c (pthread_once): Redesigned to elliminate potential