Searched full:acquire (Results 1 – 25 of 94) sorted by relevance
1234
| /Documentation/sound/cards/ |
| D | img-spdif-in.rst | 19 * name='SPDIF In Multi Frequency Acquire',index=0
20 * name='SPDIF In Multi Frequency Acquire',index=1
21 * name='SPDIF In Multi Frequency Acquire',index=2
22 * name='SPDIF In Multi Frequency Acquire',index=3
47 * name='SPDIF In Lock Acquire Threshold',index=0
|
| /Documentation/driver-api/soundwire/ |
| D | locking.rst | 42 a. Acquire Message lock.
59 <-------------------------------+ a. Acquire Message lock
72 1. Acquire lock for Bus instance associated with Master 1.
76 a. Acquire Message lock.
93 <-------------------------------+ 1. Acquire bus lock
98 <-------------------------------+ a. Acquire Message lock
|
| /Documentation/locking/ |
| D | futex-requeue-pi.rst | 91 to be able to acquire the rt_mutex before returning to user space.
93 acquire the rt_mutex as it would open a race window between the
99 allow the requeue code to acquire an uncontended rt_mutex on behalf
115 requeueing, futex_requeue() attempts to acquire the requeue target
127 tasks as it can acquire the lock for, which in the majority of cases
129 either pthread_cond_broadcast() or pthread_cond_signal() acquire the
|
| D | mutex-design.rst | 40 (i) fastpath: tries to atomically acquire the lock by cmpxchg()ing the owner with
54 to acquire the lock spinning on a local variable. It avoids expensive
97 - Point-of-acquire tracking, symbolic lookup of function names,
115 acquire the mutex and assume that the mutex_unlock() context is not using
133 Acquire the mutex, uninterruptible::
139 Acquire the mutex, interruptible::
145 Acquire the mutex, interruptible, if dec to 0::
|
| D | ww-mutex-design.rst | 63 Acquire context: To ensure eventual forward progress it is important that a task
64 trying to acquire locks doesn't grab a new reservation id, but keeps the one it
66 acquire context. Furthermore the acquire context keeps track of debugging state
67 to catch w/w mutex interface abuse. An acquire context is representing a
71 w/w mutexes, since it is required to initialize the acquire context. The lock
74 Furthermore there are three different class of w/w lock acquire functions:
99 * Functions to only acquire a single w/w mutex, which results in the exact same
103 Again this is not strictly required. But often you only want to acquire a
104 single lock in which case it's pointless to set up an acquire context (and so
119 Three different ways to acquire locks within the same w/w class. Common
[all …]
|
| D | preempt-locking.rst | 57 RULE #3: Lock acquire and release must be performed by same task
62 means you can't do oddball things like acquire a lock and go off to
64 like this, acquire and release the task in the same code path and
|
| D | rt-mutex.rst | 55 NULL 0 lock is free (fast acquire possible)
62 The fast atomic compare exchange based acquire and release is only
|
| D | lockdep-design.rst | 23 a task is attempting to acquire L2 while holding L1. From lockdep's
65 modprobe/2287 is trying to acquire lock:
131 lock will be attempted to acquire twice, which creates a deadlock,
149 deadlock - as attempts to acquire the two locks form a circle which
152 i.e., there can be any other locking sequence between the acquire-lock
417 Recursive readers, as their name indicates, are the lockers allowed to acquire
421 While non-recursive readers will cause a self deadlock if trying to acquire inside
436 read_lock() first. And when task B tries to acquire writer on X, it will block
488 lock), depending on the lock operations used to acquire it (more specifically,
624 And then because we have L1 -> L2, so the holder of L1 is going to acquire L2
|
| /Documentation/litmus-tests/ |
| D | README | 15 Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus
17 stronger than a normal acquire: both the read and write parts of
29 Demonstrate that a failing cmpxchg() operation acts as an acquire
38 acquire operation.
|
| /Documentation/litmus-tests/atomic/ |
| D | Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus | 1 C Atomic-RMW+mb__after_atomic-is-stronger-than-acquire
7 * stronger than a normal acquire: both the read and write parts of
|
| D | cmpxchg-fail-unordered-2.litmus | 7 * an acquire release operation. (In contrast, a successful cmpxchg()
8 * does act as both an acquire and a release operation.)
|
| D | cmpxchg-fail-ordered-2.litmus | 7 * operation have acquire ordering.
|
| /Documentation/ |
| D | atomic_bitops.txt | 63 Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics,
65 ACQUIRE semantics.
|
| D | memory-barriers.txt | 474 (5) ACQUIRE operations.
477 operations after the ACQUIRE operation will appear to happen after the
478 ACQUIRE operation with respect to the other components of the system.
479 ACQUIRE operations include LOCK operations and both smp_load_acquire()
482 Memory operations that occur before an ACQUIRE operation may appear to
485 An ACQUIRE operation should almost always be paired with a RELEASE
500 The use of ACQUIRE and RELEASE operations generally precludes the need
501 for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
503 ACQUIRE on a given variable, all memory accesses preceding any prior
509 This means that ACQUIRE acts as a minimal "acquire" operation and
[all …]
|
| D | atomic_t.txt | 177 {}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
233 is an ACQUIRE pattern (though very much not typical), but again the barrier is
234 strictly stronger than ACQUIRE. As illustrated:
236 C Atomic-RMW+mb__after_atomic-is-stronger-than-acquire
|
| /Documentation/core-api/ |
| D | refcount-vs-atomic.rst | 57 An ACQUIRE memory ordering guarantees that all post loads and
59 completed after the acquire operation. It also guarantees that all
61 after the acquire operation executes. This is implemented using
141 case 6) - increment-based RMW ops with acquire ordering that return a value
151 * fully ordered --> ACQUIRE ordering on success
164 * fully ordered --> RELEASE ordering + ACQUIRE ordering on success
|
| /Documentation/translations/ko_KR/ |
| D | memory-barriers.txt | 104 - Acquire vs 메모리 액세스.
493 (5) ACQUIRE 오퍼레이션.
495 이 타입의 오퍼레이션은 단방향의 투과성 배리어처럼 동작합니다. ACQUIRE
496 오퍼레이션 뒤의 모든 메모리 오퍼레이션들이 ACQUIRE 오퍼레이션 후에
499 ACQUIRE 오퍼레이션에 포함됩니다.
501 ACQUIRE 오퍼레이션 앞의 메모리 오퍼레이션들은 ACQUIRE 오퍼레이션 완료 후에
504 ACQUIRE 오퍼레이션은 거의 항상 RELEASE 오퍼레이션과 짝을 지어 사용되어야
519 ACQUIRE 와 RELEASE 오퍼레이션의 사용은 일반적으로 다른 메모리 배리어의
520 필요성을 없앱니다. 또한, RELEASE+ACQUIRE 조합은 범용 메모리 배리어처럼
523 뒤이어 같은 변수에 대해 수행된 ACQUIRE 오퍼레이션을 뒤따르는 메모리
[all …]
|
| /Documentation/RCU/ |
| D | UP.rst | 60 callback function must acquire this same lock. In this case, if
129 like spin_lock_bh() to acquire the lock. Please note that
140 callbacks acquire locks directly. However, a great many RCU
141 callbacks do acquire locks *indirectly*, for example, via
|
| D | rcu.rst | 22 not acquire any locks, perform any atomic instructions, write to
27 acquire locks can also greatly simplify deadlock-avoidance code.
|
| /Documentation/networking/ |
| D | xfrm_sysctl.rst | 11 default 30 - hard timeout in seconds for acquire requests
|
| /Documentation/translations/sp_SP/ |
| D | memory-barriers.txt | 504 (5) ACQUIRE (de adquisición).
507 toda las operaciones de memoria después de la operación ACQUIRE
508 parezcan suceder después de la ACQUIRE con respecto a los demás
509 componentes del sistema. Las operaciones ACQUIRE incluyen operaciones
512 Las operaciones de memoria que ocurren antes de una operación ACQUIRE
515 Una operación ACQUIRE casi siempre debe estar emparejada con una
530 El uso de las operaciones ACQUIRE y RELEASE generalmente excluye la
532 RELEASE+ACQUIRE NO garantiza actuar como una barrera de memoria
533 completa. Sin embargo, después de un ACQUIRE de una variable dada,
540 Esto significa que ACQUIRE actúa como una operación mínima de
[all …]
|
| /Documentation/power/ |
| D | suspend-and-cpuhotplug.rst | 40 Acquire system_transition_mutex lock
55 Acquire cpu_add_remove_lock
98 | Acquire cpu_add_remove_lock
129 Acquire cpu_add_remove_lock
|
| /Documentation/driver-api/iio/ |
| D | hw-consumer.rst | 36 /* Acquire data */
|
| /Documentation/devicetree/bindings/mfd/ |
| D | syscon-common.yaml | 13 for some other node's driver, or platform-specific code, to acquire
|
| /Documentation/filesystems/ |
| D | files.rst | 110 to just acquire a reference to the file in question under rcu using
122 either first acquire a reference or they must hold the files_lock of the
|
1234