Considerations for Using Locks

You can implement various synchronization mechanisms in the hardware or operating system.

Intel® Cilk™ Plus recognizes the locking mechanisms listed here.

The Intel® Threading Building Blocks library provides tbb::mutex to create critical code sections where it is safe to update and access shared memory or other shared resources safely. Intel® Parallel Studio tools recognize the lock and do not report a race on a memory access protected by tbb::mutex. The qsort-mutex example shows how to use a tbb::mutex.
Windows* OS: Windows CRITICAL_SECTION objects provide nearly the same functionality as tbb::mutex objects. Intel® Parallel Studio tools will not report races on accesses protected by EnterCriticalSection(), TryEnterCriticalSection(), or LeaveCriticalSection().
Linux* OS: Posix* Pthreads mutexes ( pthead_mutex_t) provide nearly the same functionality as tbb::mutex objects. Intel® Parallel Studio tools will not report races on accesses protected by pthread_mutex_lock(), pthread_mutex_trylock(), or pthread_mutex_unlock().
Intel® Parallel Studio tools recognize atomic hardware instructions, available to C/C++ programmers through compiler intrinsics

The following lock terms and facts are useful:

The following terms are interchangeable: "acquiring", "entering", or "locking" a lock (or "mutex").
A strand (or thread) that acquires a lock is said to "own" the lock.
Only the owning strand can "release", "leave", or "unlock" the lock.
Only one strand can own a lock at a time.
tbb::mutex is implemented using underlying OS mutex operations.

Lock contention can create performance problems in parallel programs. Furthermore, while locks can resolve data races, programs using locks are often non-deterministic. Avoiding locks whenever possible is recommended

These problems (and others) are described in detail in the following sections.