Lines Matching +full:spin +full:- +full:up
2 RT-mutex implementation design
12 Documentation/locking/rt-mutex.rst. Although this document does explain problems
22 ----------------------------
49 A ---+
52 C +----+
54 B +-------->
59 -------------------------
74 -----------
80 - The PI chain is an ordered series of locks and processes that cause
86 - In this document, to differentiate from locks that implement
87 PI and spin locks that are used in the PI code, from now on
91 - In this document from now on, I will use the term lock when
92 referring to spin locks that are used to protect parts of the PI
93 algorithm. These locks disable preemption for UP (when
97 spin lock
98 - Same as lock above.
101 - A waiter is a struct that is stored on the stack of a blocked
111 on a mutex. This is the same as waiter->task.
114 - A list of processes that are blocked on a mutex.
117 - The highest priority process waiting on a specific mutex.
120 - The highest priority process waiting on one of the mutexes
129 --------
152 E->L4->D->L3->C->L2->B->L1->A
159 F->L5->B->L1->A
166 E->L4->D->L3->C->L2-+
168 +->B->L1->A
170 F->L5-+
180 G->L2->B->L1->A
185 E->L4->D->L3->C-+
186 +->L2-+
188 G-+ +->B->L1->A
190 F->L5-+
192 If process G has the highest priority in the chain, then all the tasks up
197 ------------------
201 by a spin lock that is located in the struct of the mutex. This lock is called
206 ------------
219 pi_waiters. It is protected by a spin lock also in the task structure,
225 ---------------------
231 The following shows a locking order of L1->L2->L3, but may not actually
286 And thus we have the chain A->L1->B->L2->C->L3->D.
293 Now since mutexes can be defined by user-land applications, we don't want a DOS
295 PI chain, and have the code holding spin locks while looking at a large
302 ---------------------
311 See Documentation/locking/rt-mutex.rst for further details.
314 --------------
347 --------------------
382 ----------------------------------------
386 The implementation has gone through several iterations, and has ended up
418 ------------------------------------
470 --------------------
492 Waking up in the loop
493 ---------------------
495 The task can then wake up for a couple of reasons:
507 that can wake up before getting the lock, either due to a signal or
510 lock held, otherwise it will return with -EINTR if the task was woken
511 by a signal, or -ETIMEDOUT if it timed out.
515 -------------------
534 in the slow path too. If a waiter of a mutex woke up because of a signal
541 If there are waiters, then we need to wake one up.
543 On the wake up code, the pi_lock of the current owner is taken. The top
548 Finally we unlock the pi_lock of the pending owner and wake it up.
552 -------
558 -------
562 Updated: Alex Shi <alex.shi@linaro.org> - 7/6/2017
571 -------
573 This document was originally written for 2.6.17-rc3-mm1