''v-2-0-0-release

1 files changed, 63 insertions, 58 deletions

diff --git a/ChangeLog b/ChangeLog
index 93dbd1b..cba504f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,75 +1,80 @@
-2005-03-14  Ross Johnson  <ross at callisto.canberra.edu.au>
+2005-03-16  Ross Johnson  <ross at callisto.canberra.edu.au>^M
 
-	* pthread_once.c (pthread_once): Downgrade interlocked operations to simple
-	memory operations where these are protected by the critical section; edit
-	comments.
+        * pthread_setcancelstate.c: Don't check for an async cancel event
+        if the library is using alertable async cancel..
 
-2005-03-13  Ross Johnson  <rpj at callisto.canberra.edu.au>
+2005-03-14  Ross Johnson  <ross 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.
+	* pthread_once.c (pthread_once): Downgrade interlocked operations to simple

+	memory operations where these are protected by the critical section; edit

+	comments.

+
+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).
+	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).
+	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:-
+	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
+	  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.
+	[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.
+	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.
+	* 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
-	starvation problem.
-	- reported by Gottlob Frege  <gottlobfrege at gmail.com>
+	* pthread_once.c (pthread_once): Redesigned to elliminate potential

+	starvation problem.

+	- reported by Gottlob Frege  <gottlobfrege at gmail.com>

 
-	* ptw32_threadDestroy.c (ptw32_threadDestroy): Implicit threads were
-	not closing their Win32 thread duplicate handle.
-	- reported by Dmitrii Semii <bogolt at gmail.com>
+	* ptw32_threadDestroy.c (ptw32_threadDestroy): Implicit threads were

+	not closing their Win32 thread duplicate handle.

+	- reported by Dmitrii Semii <bogolt at gmail.com>

 
 2005-01-25  Ralf Kubis  <RKubis at mc.com>