diff options
Diffstat (limited to 'ChangeLog')
| -rw-r--r-- | ChangeLog | 121 |
1 files changed, 63 insertions, 58 deletions
@@ -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>
|