[commits] r9218 - in /trunk/linuxthreads/linuxthreads: ChangeLog.eglibc man/pthread_mutex_init.man

[joseph@xxxxxxxxxx]

Author: joseph
Date: Tue Nov 10 17:01:35 2009
New Revision: 9218

Log:
2009-11-10  Samuel Thibault  <samuel.thibault@xxxxxxxxxxxx>

	* man/pthread_mutex_init.man: Document that recursive mutexes
	check that the caller is the owner of the lock.

Added:
    trunk/linuxthreads/linuxthreads/ChangeLog.eglibc
Modified:
    trunk/linuxthreads/linuxthreads/man/pthread_mutex_init.man

Added: trunk/linuxthreads/linuxthreads/ChangeLog.eglibc
==============================================================================
--- trunk/linuxthreads/linuxthreads/ChangeLog.eglibc (added)
+++ trunk/linuxthreads/linuxthreads/ChangeLog.eglibc Tue Nov 10 17:01:35 2009
@@ -1,0 +1,9 @@
+2009-11-10  Samuel Thibault  <samuel.thibault@xxxxxxxxxxxx>
+
+	* man/pthread_mutex_init.man: Document that recursive mutexes
+	check that the caller is the owner of the lock.
+
+Local Variables:
+mode: change-log
+change-log-default-name: "ChangeLog.eglibc"
+End:

Modified: trunk/linuxthreads/linuxthreads/man/pthread_mutex_init.man
==============================================================================
--- trunk/linuxthreads/linuxthreads/man/pthread_mutex_init.man (original)
+++ trunk/linuxthreads/linuxthreads/man/pthread_mutex_init.man Tue Nov 10 17:01:35 2009
@@ -88,14 +88,14 @@
 the calling thread), and only when this count reaches zero is the
 mutex actually unlocked.
 
-On ``error checking'' mutexes, !pthread_mutex_unlock! actually checks
-at run-time that the mutex is locked on entrance, and that it was
-locked by the same thread that is now calling !pthread_mutex_unlock!.
-If these conditions are not met, an error code is returned and the
-mutex remains unchanged.  ``Fast'' and ``recursive'' mutexes perform
-no such checks, thus allowing a locked mutex to be unlocked by a
-thread other than its owner. This is non-portable behavior and must
-not be relied upon.
+On ``error checking'' and ``recursive'' mutexes,
+!pthread_mutex_unlock! actually checks at run-time that the mutex is
+locked on entrance, and that it was locked by the same thread that is
+now calling !pthread_mutex_unlock!.  If these conditions are not met,
+an error code is returned and the mutex remains unchanged.  ``Fast''
+mutexes perform no such checks, thus allowing a locked mutex to be
+unlocked by a thread other than its owner. This is non-portable behavior
+and must not be relied upon.
 
 !pthread_mutex_destroy! destroys a mutex object, freeing the resources
 it might hold. The mutex must be unlocked on entrance. In the