| Skip Navigation Links | |
| Exit Print View | |
 | man pages section 5: Standards, Environments, and Macros Oracle Solaris 11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
| man pages section 5: Standards, Environments, and Macros Oracle Solaris 11 Information Library |
- concepts relating to mutual exclusion locks
Mutual exclusion locks (mutexes) prevent multiple threads from simultaneously executing critical sectionsof code which access shared data (that is, mutexes are used toserialize the execution of threads). All mutexes must be global. A successfulcall to acquire a mutex will cause another thread that is also tryingto lock the same mutex to block until the owner thread unlocksthe mutex.
Mutexes can synchronize threads within the same process or in other processes.Mutexes can be used to synchronize threads between processes if the mutexesare allocated in writable memory and shared among the cooperating processes (seemmap(2)), and have been initialized for this task.
The following table lists mutex functions and the actions they perform.
|
Mutexes are either intra-process or inter-process, depending upon the argument passed implicitlyor explicitly to the initialization of that mutex. A statically allocated mutexdoes not need to be explicitly initialized; by default, a statically allocatedmutex is initialized with all zeros and its scope is set to bewithin the calling process.
For inter-process synchronization, a mutex needs to be allocated in memory sharedbetween these processes. Since the memory for such a mutex must beallocated dynamically, the mutex needs to be explicitly initialized with the appropriateattribute that indicates inter-process use.
A critical section of code is enclosed by a call to lockthe mutex and the call to unlock the mutex to protect itfrom simultaneous access by multiple threads. Only one thread at a timemay possess mutually exclusive access to the critical section of code thatis enclosed by the mutex-locking call and the mutex-unlocking call, whether the mutex'sscope is intra-process or inter-process. A thread calling to lock the mutexeither gets exclusive access to the code starting from the successfullocking until its call to unlock the mutex, or it waits untilthe mutex is unlocked by the thread that locked it.
Mutexes have ownership, unlike semaphores. Only the thread that locked a mutex,(that is, the owner of the mutex), should unlock it.
If a thread waiting for a mutex receives a signal, upon returnfrom the signal handler, the thread resumes waiting for the mutex asif there was no interrupt.
Mutexes are almost like data – they can be embedded in datastructures, files, dynamic or static memory, and so forth. Hence, theyare easy to introduce into a program. However, too many mutexes candegrade performance and scalability of the application. Because too few mutexes can hinderthe concurrency of the application, they should be introduced with care. Also,incorrect usage (such as recursive calls, or violation of locking order, andso forth) can lead to deadlocks, or worse, data inconsistencies.
Seeattributes(5) for descriptions of the following attributes:
|
mmap(2),shmop(2),mutex_destroy(3C),mutex_init(3C),mutex_lock(3C),mutex_trylock(3C),mutex_unlock(3C),pthread_create(3C),pthread_mutex_destroy(3C),pthread_mutex_init(3C),pthread_mutex_lock(3C),pthread_mutex_trylock(3C),pthread_mutex_unlock(3C),pthread_mutexattr_init(3C),attributes(5),standards(5)
In the current implementation of threads,pthread_mutex_lock(),pthread_mutex_unlock(),mutex_lock()mutex_unlock(),pthread_mutex_trylock(), andmutex_trylock() do not validate the mutex type. Therefore, an uninitialized mutex or amutex with an invalid type does not returnEINVAL. Interfaces for mutexeswith an invalid type have unspecified behavior.
By default, if multiple threads are waiting for a mutex, the orderof acquisition is undefined.
The system does not support multiple mappings to the same logical synchobject if it is initialized as process-private (USYNC_THREAD for Solaris,PTHREAD_PROCESS_PRIVATE forPOSIX). If you need tommap(2)a synch object to different locations withinthe same address space, then the synch object should be initialized asa shared object (USYNC_PROCESS for Solaris,PTHREAD_PROCESS_SHARED for POSIX).
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.Legal Notices |   |