Lines Matching refs:thread

24   by the thread that has locked it. A count of zero indicates that the mutex
27 * An **owning thread** that identifies the thread that has locked the mutex,
33 A thread that needs to use a shared resource must first gain exclusive rights
35 by another thread, the requesting thread may choose to wait for the mutex
38 After locking a mutex, the thread may safely use the associated resource
41 that want to use the resource. When the thread no longer needs the resource
46 thread that has waited the longest.
54 A thread is permitted to lock a mutex it has already locked.
55 This allows the thread to access the associated resource at a point
58 A mutex that is repeatedly locked by a thread must be unlocked an equal number
60 by another thread.
65 The thread that has locked a mutex is eligible for :dfn:`priority inheritance`.
66 This means the kernel will *temporarily* elevate the thread's priority
67 if a higher priority thread begins waiting on the mutex. This allows the owning
68 thread to complete its work and release the mutex more rapidly by executing
69 at the same priority as the waiting thread. Once the mutex has been unlocked,
70 the unlocking thread resets its priority to the level it had before locking
75     how high the kernel can raise a thread's priority due to priority
78 The owning thread's base priority is saved in the mutex when it obtains the
79 lock. Each time a higher priority thread waits on a mutex, the kernel adjusts
80 the owning thread's priority. When the owning thread releases the lock (or if
81 the high priority waiting thread times out), the kernel restores the thread's
87 owning thread's priority was previously raised. Consequently it is recommended
88 that a thread lock only a single mutex at a time when multiple mutexes are
123 for the mutex to become available if it is already locked by another thread.
146 and unlocks the mutex that was previously locked by the thread.