Date: Wed, 26 Jun 2013 21:21:49 GMT From: John Baldwin <jhb@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 230190 for review Message-ID: <201306262121.r5QLLn28086423@skunkworks.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://p4web.freebsd.org/@@230190?ac=10 Change 230190 by jhb@jhb_jhbbsd on 2013/06/26 21:21:08 Finish review of this. Affected files ... .. //depot/projects/smpng/share/man/man9/locking.9#14 edit Differences ... ==== //depot/projects/smpng/share/man/man9/locking.9#14 (text+ko) ==== @@ -42,14 +42,10 @@ A thread acquires (locks) a mutex before accessing data shared with other threads (including interrupt threads), and releases (unlocks) it afterwards. If the mutex cannot be acquired, the thread requesting it will wait. -Mutexes are by default adaptive, meaning that +Mutexes are adaptive by default, meaning that if the owner of a contended mutex is currently running on another CPU, -then a thread attempting to acquire the mutex will briefly spin -in the hope that the owner is only briefly holding it, -and might release it shortly. -If the owner does not do so, the waiting thread proceeds to yield the processor, -allowing other threads to run. -If the owner is not currently actually running then the spin step is skipped. +then a thread attempting to acquire the mutex will spin rather than yielding +the processor. Mutexes fully support priority propagation. .Pp See @@ -62,8 +58,10 @@ Note that a thread that holds a spin mutex must never yield its CPU to avoid deadlock. Unlike ordinary mutexes, spin mutexes disable interrupts when acquired. -Since disabling interrupts can be expensive, they are generally slower. -Spin mutexes should be used only when necessary, e.g. to protect data shared +Since disabling interrupts can be expensive, they are generally slower to +acquire and release. +Spin mutexes should be used only when absolutely necessary, +e.g. to protect data shared with interrupt filter code (see .Xr bus_setup_intr 9 for details), @@ -161,15 +159,15 @@ for details. .Ss Condition variables Condition variables are used in conjunction with locks to wait for -conditions to occur. -A thread must hold the associated lock before calling the -.Fn cv_wait* , +a condition to become true. +A thread must hold the associated lock before calling one of the +.Fn cv_wait , functions. When a thread waits on a condition, the lock -is atomically released before the thread yields the processor, -then reacquired before the function call returns. -Condition variables can be used with blocking mutexes, -reader/writer locks, and shared/exclusive locks. +is atomically released before the thread yields the processor +and reacquired before the function call returns. +Condition variables may be used with blocking mutexes, +reader/writer locks, read-mostly locks, and shared/exclusive locks. .Pp See .Xr condvar 9 @@ -183,7 +181,12 @@ .Fn wakeup , and .Fn wakeup_one -handle event-based thread blocking. +also handle event-based thread blocking. +Unlike condition variables, +arbitrary addresses may be used as wait channels and an dedicated +structure does not need to be allocated. +However, care must be taken to ensure that wait channel addresses are +unique to an event. If a thread must wait for an external event, it is put to sleep by .Fn tsleep , .Fn msleep , @@ -203,9 +206,10 @@ All threads sleeping on a single .Fa chan are woken up later by -.Fn wakeup , -often called from inside an interrupt routine, to indicate that the -resource the thread was blocking on is available now. +.Fn wakeup +.Pq often called from inside an interrupt routine +to indicate that the +event the thread was blocking on has occurred. .Pp Several of the sleep functions including .Fn msleep , @@ -221,7 +225,7 @@ flag, then the lock will not be reacquired before returning. The lock is used to ensure that a condition can be checked atomically, and that the current thread can be suspended without missing a -change to the condition, or an associated wakeup. +change to the condition or an associated wakeup. In addition, all of the sleep routines will fully drop the .Va Giant mutex @@ -232,6 +236,14 @@ .Pq restoring any recursion before the function returns. .Pp +The +.Fn pause +function is a special sleep function that waits for a specified +amount of time to pass before the thread resumes execution. +This sleep cannot be terminated early by either an explicit +.Fn wakeup +or a signal. +.Pp See .Xr sleep 9 for details. @@ -258,103 +270,123 @@ There are places in the kernel that drop Giant and pick it back up again. Sleep locks will do this before sleeping. -Parts of the network or VM code may do this as well, depending on the -setting of a sysctl. +Parts of the network or VM code may do this as well. This means that you cannot count on Giant keeping other code from running if your code sleeps, even if you want it to. .El .Sh INTERACTIONS -The primitives interact and have a number of rules regarding how +The primitives can interact and have a number of rules regarding how they can and can not be combined. Many of these rules are checked by .Xr witness 4 . -.Ss Bounded vs. unbounded sleep -A bounded sleep i - -The following primitives perform bounded sleep: -mutexes, pool mutexes, reader/writer locks and read-mostly locks. +.Ss Bounded vs. Unbounded Sleep +A bounded sleep +.Pq or blocking +is a sleep where the only resource needed to resume execution of a thread +is CPU time for the owner of a lock that the thread is waiting to acquire. +An unbounded sleep +.Po +often referred to as simply +.Dq sleeping +.Pc +is a sleep where a thread is waiting for an external event or for a condition +to become true. +In particular, +since there is always CPU time available, +a dependency chain of threads in bounded sleeps should always make forward +progress. +This requires that no thread in a bounded sleep is waiting for a lock held +by a thread in an unbounded sleep. +To avoid priority inversions, +a thread in a bounded sleep lends its priority to the owner of the lock +that it is waiting for. .Pp -The following primitives may perform an unbounded sleep: -shared/exclusive locks, counting semaphores, condition variables, sleep/wakeup and lockmanager locks. +The following primitives perform bounded sleeps: +mutexes, reader/writer locks and read-mostly locks. .Pp +The following primitives perform unbounded sleeps: +sleepable read-mostly locks, shared/exclusive locks, lockmanager locks, +counting semaphores, condition variables, and sleep/wakeup. +.Ss General Principles +.Bl -bullet +.It It is an error to do any operation that could result in yielding the processor while holding a spin mutex. -.Pp -As a general rule, it is an error to do any operation that could result -in unbounded sleep while holding any primitive from the 'bounded sleep' group. +.It +It is an error to do any operation that could result in unbounded sleep +while holding any primitive from the 'bounded sleep' group. For example, it is an error to try to acquire shared/exclusive lock while -holding mutex, or to try to allocate memory with M_WAITOK while holding +holding mutex, or to try to allocate memory with M_WAITOK while holding a read-write lock. .Pp -As a special case, it is possible to call +Note that the lock passed to one of the .Fn sleep or -.Fn mtx_sleep -while holding a single mutex. -It will atomically drop that mutex and reacquire it as part of waking up. -This is often a bad idea because it generally relies on the programmer having -good knowledge of all of the call graph above the place where -.Fn mtx_sleep -is being called and assumptions the calling code has made. -Because the lock gets dropped during sleep, one must re-test all -the assumptions that were made before, all the way up the call graph to the -place where the lock was acquired. -.Pp +.Fn cv_wait +functions is dropped before the thread enters the unbounded sleep and does +not violate this rule. +.It It is an error to do any operation that could result in yielding of the processor when running inside an interrupt filter. -.Pp +.It It is an error to do any operation that could result in unbounded sleep when running inside an interrupt thread. +.El .Ss Interaction table The following table shows what you can and can not do while holding -one of the synchronization primitives discussed: -.Bl -column ".Ic xxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXX" -offset indent -.It Em " You want:" Ta spin-mtx Ta mutex Ta rwlock Ta rmlock Ta sx Ta sleep -.It Em "You have: " Ta ------ Ta ------ Ta ------ Ta ------ Ta ------ Ta ------ -.It spin mtx Ta \&ok-1 Ta \&no Ta \&no Ta \&no Ta \&no Ta \&no-3 -.It mutex Ta \&ok Ta \&ok-1 Ta \&ok Ta \&ok Ta \&no Ta \&no-3 -.It rwlock Ta \&ok Ta \&ok Ta \&ok-2 Ta \&ok Ta \&no Ta \&no-3 -.It rmlock Ta \&ok Ta \&ok Ta \&ok Ta \&ok-2 Ta \&no-5 Ta \&no-5 -.It sx Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&no-2 Ta \&ok-4 +one of the locking primitives discussed. Note that +.Dq sleep +includes +.Fn sema_wait , +.Fn sema_timedwait , +any of the +.Fn cv_wait +functions, +and any of the +.Fn sleep +functions. +.Bl -column ".Ic xxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXX" -offset 3n +.It Em " You want:" Ta spin mtx Ta mutex/rw Ta rmlock Ta sleep rm Ta sx/lk Ta sleep +.It Em "You have: " Ta -------- Ta -------- Ta ------ Ta -------- Ta ------ Ta ------ +.It spin mtx Ta \&ok Ta \&no Ta \&no Ta \&no Ta \&no Ta \&no-1 +.It mutex/rw Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no-1 +.It rmlock Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no-1 +.It sleep rm Ta \&ok Ta \&ok Ta \&ok Ta \&ok-2 Ta \&ok-2 Ta \&ok-2/3 +.It sx Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok-3 +.It lockmgr Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok .El .Pp .Em *1 -Recursion is defined per lock. -Lock order is important. +There are calls that atomically release this primitive when going to sleep +and reacquire it on wakeup +.Po +.Fn mtx_sleep , +.Fn rw_sleep , +.Fn msleep_spin , +etc. +.Pc . .Pp .Em *2 -Readers can recurse though writers can not. -Lock order is important. +These cases are only allowed while holding a write lock on a sleepable +read-mostly lock. .Pp .Em *3 -There are calls that atomically release this primitive when going to sleep -and reacquire it on wakeup (e.g. -.Fn mtx_sleep , -.Fn rw_sleep -and -.Fn msleep_spin ) . -.Pp -.Em *4 -Though one can sleep holding an sx lock, one can also use -.Fn sx_sleep -which will atomically release this primitive when going to sleep and +Though one can sleep while holding this lock, +one can also use a +.Fn sleep +function to atomically release this primitive when going to sleep and reacquire it on wakeup. .Pp -.Em *5 -.Em Read-mostly -locks can be initialized to support sleeping while holding a write lock. -See -.Xr rmlock 9 -for details. +Note that non-blocking try operations on locks are always permitted. .Ss Context mode table The next table shows what can be used in different contexts. At this time this is a rather easy to remember table. -.Bl -column ".Ic Xxxxxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXX" -offset indent -.It Em "Context:" Ta spin mtx Ta mutex Ta sx Ta rwlock Ta rmlock Ta sleep +.Bl -column ".Ic Xxxxxxxxxxxxxxxxxxx" ".Xr XXXXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXXX" ".Xr XXXXXXXXX" ".Xr XXXXXX" -offset 3n +.It Em "Context:" Ta spin mtx Ta mutex/rw Ta rmlock Ta sleep rm Ta sx/lk Ta sleep .It interrupt filter: Ta \&ok Ta \&no Ta \&no Ta \&no Ta \&no Ta \&no -.It interrupt thread: Ta \&ok Ta \&ok Ta \&no Ta \&ok Ta \&ok Ta \&no -.It callout: Ta \&ok Ta \&ok Ta \&no Ta \&ok Ta \&no Ta \&no -.It syscall: Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok +.It interrupt thread: Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no +.It callout: Ta \&ok Ta \&ok Ta \&ok Ta \&no Ta \&no Ta \&no +.It system call: Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok Ta \&ok .El .Sh SEE ALSO .Xr witness 4 ,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306262121.r5QLLn28086423>