Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa...

[sfrench/cifs-2.6.git] / Documentation / futex-requeue-pi.txt

diff --git a/Documentation/futex-requeue-pi.txt b/Documentation/futex-requeue-pi.txt
index 77b36f59d16b452bbf12bba4e3db83ec3ea84a9f..14ab5787b9a77cd485899c704aef0212634aa212 100644 (file)
--- a/Documentation/futex-requeue-pi.txt
+++ b/Documentation/futex-requeue-pi.txt
@@ -1,5 +1,6 @@
+================

 Futex Requeue PI
 Futex Requeue PI

-----------------
+================

 
 Requeueing of tasks from a non-PI futex to a PI futex requires
 special handling in order to ensure the underlying rt_mutex is never
 
 Requeueing of tasks from a non-PI futex to a PI futex requires
 special handling in order to ensure the underlying rt_mutex is never


@@ -20,28 +21,28 @@ implementation would wake the highest-priority waiter, and leave the
 rest to the natural wakeup inherent in unlocking the mutex
 associated with the condvar.
 
 rest to the natural wakeup inherent in unlocking the mutex
 associated with the condvar.
 

-Consider the simplified glibc calls:
-
-/* caller must lock mutex */
-pthread_cond_wait(cond, mutex)
-{
-       lock(cond->__data.__lock);
-       unlock(mutex);
-       do {
-          unlock(cond->__data.__lock);
-          futex_wait(cond->__data.__futex);
-          lock(cond->__data.__lock);
-       } while(...)
-       unlock(cond->__data.__lock);
-       lock(mutex);
-}
-
-pthread_cond_broadcast(cond)
-{
-       lock(cond->__data.__lock);
-       unlock(cond->__data.__lock);
-       futex_requeue(cond->data.__futex, cond->mutex);
-}
+Consider the simplified glibc calls::
+
+       /* caller must lock mutex */
+       pthread_cond_wait(cond, mutex)
+       {
+               lock(cond->__data.__lock);
+               unlock(mutex);
+               do {
+               unlock(cond->__data.__lock);
+               futex_wait(cond->__data.__futex);
+               lock(cond->__data.__lock);
+               } while(...)
+               unlock(cond->__data.__lock);
+               lock(mutex);
+       }
+
+       pthread_cond_broadcast(cond)
+       {
+               lock(cond->__data.__lock);
+               unlock(cond->__data.__lock);
+               futex_requeue(cond->data.__futex, cond->mutex);
+       }

 
 Once pthread_cond_broadcast() requeues the tasks, the cond->mutex
 has waiters. Note that pthread_cond_wait() attempts to lock the
 
 Once pthread_cond_broadcast() requeues the tasks, the cond->mutex
 has waiters. Note that pthread_cond_wait() attempts to lock the


@@ -53,29 +54,29 @@ In order to support PI-aware pthread_condvar's, the kernel needs to
 be able to requeue tasks to PI futexes.  This support implies that
 upon a successful futex_wait system call, the caller would return to
 user space already holding the PI futex.  The glibc implementation
 be able to requeue tasks to PI futexes.  This support implies that
 upon a successful futex_wait system call, the caller would return to
 user space already holding the PI futex.  The glibc implementation

-would be modified as follows:
-
-
-/* caller must lock mutex */
-pthread_cond_wait_pi(cond, mutex)
-{
-       lock(cond->__data.__lock);
-       unlock(mutex);
-       do {
-          unlock(cond->__data.__lock);
-          futex_wait_requeue_pi(cond->__data.__futex);
-          lock(cond->__data.__lock);
-       } while(...)
-       unlock(cond->__data.__lock);
-        /* the kernel acquired the mutex for us */
-}
-
-pthread_cond_broadcast_pi(cond)
-{
-       lock(cond->__data.__lock);
-       unlock(cond->__data.__lock);
-       futex_requeue_pi(cond->data.__futex, cond->mutex);
-}
+would be modified as follows::
+
+
+       /* caller must lock mutex */
+       pthread_cond_wait_pi(cond, mutex)
+       {
+               lock(cond->__data.__lock);
+               unlock(mutex);
+               do {
+               unlock(cond->__data.__lock);
+               futex_wait_requeue_pi(cond->__data.__futex);
+               lock(cond->__data.__lock);
+               } while(...)
+               unlock(cond->__data.__lock);
+               /* the kernel acquired the mutex for us */
+       }
+
+       pthread_cond_broadcast_pi(cond)
+       {
+               lock(cond->__data.__lock);
+               unlock(cond->__data.__lock);
+               futex_requeue_pi(cond->data.__futex, cond->mutex);
+       }

 
 The actual glibc implementation will likely test for PI and make the
 necessary changes inside the existing calls rather than creating new
 
 The actual glibc implementation will likely test for PI and make the
 necessary changes inside the existing calls rather than creating new