Searched refs:locks (Results 1 – 5 of 5) sorted by relevance
18 lock, and each holds some of the locks the other threads need to38 - Avoid needing to hold two locks at the same time. Break your43 - Always acquire locks in the same order. For example, if you have46 sanctum" one first. Another example is "acquire locks in47 alphabetical order" in a situation where the locks have names. Or48 if the locks are unnamed, acquire locks in order of the mutex’s52 - Use atomic operations instead of locks.61 Another common problem with locks is *convoying*. Convoying occurs73 To avoid convoying, use atomic operations instead of locks where
11 *reader locks* from *writer locks.* There can be more than one reader
9 exclusion is implemented by *mutexes* and *locks.* A mutex is an object49 The constructor for ``scoped_lock`` waits until there are no other locks97 If you are familiar with C interfaces for locks, you may be wondering
67 *reader* locks.71 *reader* locks.
96 oneapi::tbb::spin_mutex* locks; // a lock for each vertex variable131 oneapi::tbb::spin_mutex::scoped_lock l(locks[u]); in shortpath_helper()143 oneapi::tbb::spin_mutex::scoped_lock l(locks[v]); in shortpath_helper()220 locks = new oneapi::tbb::spin_mutex[N]; in InitializeGraph()260 delete[] locks; in ReleaseGraph()