summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorrpj <rpj>2005-01-25 05:38:44 +0000
committerrpj <rpj>2005-01-25 05:38:44 +0000
commit2c2624655dfa830dafef17e87b739f876f098f8c (patch)
tree3ddbbf98d7ccd7d31badab2cc78ed2de7161046b
parente1d015c3dc92a70d787a5686bc7518c6f42fe81f (diff)
''
-rw-r--r--ANNOUNCE6
-rw-r--r--CONTRIBUTORS1
-rw-r--r--ChangeLog7
-rw-r--r--NEWS13
4 files changed, 25 insertions, 2 deletions
diff --git a/ANNOUNCE b/ANNOUNCE
index ddd35f1..f326044 100644
--- a/ANNOUNCE
+++ b/ANNOUNCE
@@ -1,10 +1,14 @@
- PTHREADS-WIN32 SNAPSHOT 2005-01-03
+ PTHREADS-WIN32 SNAPSHOT 2005-01-25
----------------------------------
Web Site: http://sources.redhat.com/pthreads-win32/
FTP Site: ftp://sources.redhat.com/pub/pthreads-win32
Maintainer: Ross Johnson <rpj@callisto.canberra.edu.au>
+[Please note: snapshots from 2004-11-03 are using a new mutex implementation
+and should be regarded as beta code. You may not want to use it in production
+yet but please try it if you can.]
+
We are pleased to announce the availability of a new snapshot of
Pthreads-win32, an Open Source Software implementation of the
Threads component of the POSIX 1003.1 2001 Standard for Microsoft's
diff --git a/CONTRIBUTORS b/CONTRIBUTORS
index 115e9dd..c23ce98 100644
--- a/CONTRIBUTORS
+++ b/CONTRIBUTORS
@@ -74,6 +74,7 @@ Alexander Terekhov TEREKHOV at de dot ibm dot com
condition variables;
enhancements to semaphores;
enhancements to mutexes;
+ new mutex implementation in 'futex' style;
system clock change handling re CV timeouts;
bug fixes.
Thomas Pfaff tpfaff at gmx dot net
diff --git a/ChangeLog b/ChangeLog
index 7e4595c..e4f78b2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,10 +1,15 @@
+2005-01-25 Ralf Kubis <RKubis at mc.com>
+
+ * Attempted acquisition of recursive mutex was causing waiting
+ threads to not be woken when the mutex is released.
+
2005-01-01 Konstantin Voronkov <beowinkle at yahoo.com>
* pthread_mutex_lock.c (pthread_mutex_lock): The new atomic exchange
mutex algorithm is known to allow a thread to steal the lock off
FIFO waiting threads. The next waiting FIFO thread gets a spurious
wake-up and must attempt to re-acquire the lock. The woken thread
- was setting itself as the the mutex's owner before the re-acquisition.
+ was setting itself as the mutex's owner before the re-acquisition.
2004-11-22 Ross Johnson <rpj at callisto.canberra.edu.au>
diff --git a/NEWS b/NEWS
index f234e1f..fa2d369 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+SNAPSHOT 2005-01-25
+-------------------
+
+Bug fixes
+---------
+
+* Attempted acquisition of a recursive mutex could cause waiting threads
+to not be woken when the mutex was released.
+- Ralf Kubis <RKubis at mc.com>
+
+* Various package omissions have been fixed.
+
+
SNAPSHOT 2005-01-03
-------------------