| Skip Navigation Links | |
| Exit Print View | |
 | man pages section 3: Basic Library Functions Oracle Solaris 11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
| man pages section 3: Basic Library Functions Oracle Solaris 11 Information Library |
enable_extended_FILE_stdio(3C)
posix_spawnattr_getschedparam(3C)
posix_spawnattr_getschedpolicy(3C)
posix_spawnattr_getsigdefault(3C)
posix_spawnattr_getsigignore_np(3C)
posix_spawnattr_getsigmask(3C)
posix_spawnattr_setschedparam(3C)
posix_spawnattr_setschedpolicy(3C)
posix_spawnattr_setsigdefault(3C)
posix_spawnattr_setsigignore_np(3C)
posix_spawnattr_setsigmask(3C)
posix_spawn_file_actions_addclose(3C)
posix_spawn_file_actions_addclosefrom_np(3C)
posix_spawn_file_actions_adddup2(3C)
posix_spawn_file_actions_addopen(3C)
posix_spawn_file_actions_destroy(3C)
posix_spawn_file_actions_init(3C)
pthread_attr_getdetachstate(3C)
pthread_attr_getinheritsched(3C)
pthread_attr_getschedparam(3C)
pthread_attr_getschedpolicy(3C)
pthread_attr_setdetachstate(3C)
pthread_attr_setinheritsched(3C)
pthread_attr_setschedparam(3C)
pthread_attr_setschedpolicy(3C)
pthread_barrierattr_destroy(3C)
pthread_barrierattr_getpshared(3C)
pthread_barrierattr_setpshared(3C)
pthread_condattr_getpshared(3C)
pthread_condattr_setpshared(3C)
pthread_cond_reltimedwait_np(3C)
pthread_key_create_once_np(3C)
pthread_mutexattr_getprioceiling(3C)
pthread_mutexattr_getprotocol(3C)
pthread_mutexattr_getpshared(3C)
pthread_mutexattr_getrobust(3C)
pthread_mutexattr_setprioceiling(3C)
pthread_mutexattr_setprotocol(3C)
pthread_mutexattr_setpshared(3C)
pthread_mutexattr_setrobust(3C)
pthread_mutex_getprioceiling(3C)
pthread_mutex_reltimedlock_np(3C)
pthread_mutex_setprioceiling(3C)
pthread_rwlockattr_destroy(3C)
pthread_rwlockattr_getpshared(3C)
pthread_rwlockattr_setpshared(3C)
pthread_rwlock_reltimedrdlock_np(3C)
pthread_rwlock_reltimedwrlock_np(3C)
pthread_rwlock_timedrdlock(3C)
pthread_rwlock_timedwrlock(3C)
rctlblk_get_enforced_value(3C)
- mutual exclusion locks
cc –mt [flag... ]file... [library... ]#include <thread.h> #include <synch.h>intmutex_init(mutex_t *mp,inttype,void *arg);
intmutex_lock(mutex_t *mp);
intmutex_trylock(mutex_t *mp);
intmutex_unlock(mutex_t *mp);
intmutex_consistent(mutex_t *mp);
intmutex_destroy(mutex_t *mp);
Mutual exclusion locks (mutexes) prevent multiple threads from simultaneously executing critical sectionsof code that access shared data (that is, mutexes are used toserialize the execution of threads). All mutexes must be global. A successfulcall for a mutex lock by way ofmutex_lock() will causeanother thread that is also trying to lock the same mutex toblock until the owner thread unlocks it by way ofmutex_unlock().Threads within the same process or within other processes can share mutexes.
Mutexes can synchronize threads within the same process or in other processes. Mutexes can be used to synchronize threads between processes if themutexes are allocated in writable memory and shared among the cooperating processes(seemmap(2)), and have been initialized for this task.
Mutexes are either intra-process or inter-process, depending upon the argument passedimplicitly or explicitly to the initialization of that mutex. A staticallyallocated mutex does not need to be explicitly initialized; by default,a statically allocated mutex is initialized with all zeros and its scopeis set to be within the calling process.
For inter-process synchronization, a mutex needs to be allocated in memoryshared between these processes. Since the memory for such a mutex mustbe allocated dynamically, the mutex needs to be explicitly initialized usingmutex_init().
Themutex_init() function initializes the mutex referenced bymp with thetype specified bytype. Upon successful initialization the state of themutex becomes initialized and unlocked. Only the attribute typeLOCK_PRIO_PROTECT usesarg.Thetype argument must be one of the following:
The mutex can synchronize threads only in this process.
The mutex can synchronize threads in this process and other processes. The object initialized with this attribute must be allocated in memory shared between processes, either in System V shared memory (seeshmop(2)) or in memory mapped to a file (seemmap(2)). If the object is not allocated in such shared memory, it will not be shared between processes.
Thetype argument can be augmented by the bitwise-inclusive-OR of zero ormore of the following flags:
The mutex can synchronize threads robustly. At the time of thread or process death, either by callingthr_exit() orexit() or due to process abnormal termination, the lock is unlocked if is held by the thread or process. The next owner of the mutex will acquire it with an error return ofEOWNERDEAD. The application must always check the return value frommutex_lock() for a mutex of this type. The new owner of this mutex should then attempt to make the state protected by the mutex consistent, since this state could have been left inconsistent when the last owner died. If the new owner is able to make the state consistent, it should callmutex_consistent() to restore the state of the mutex and then unlock the mutex. All subsequent calls tomutex_lock()will then behave normally. Only the new owner can make the mutex consistent. If for any reason the new owner is not able to make the state consistent, it should not callmutex_consistent() but should simply unlock the mutex. All waiting processes will be awakened and all subsequent calls tomutex_lock() will fail in acquiring the mutex with an error value ofENOTRECOVERABLE. If the thread or process that acquired the lock withEOWNERDEAD terminates without unlocking the mutex, the next owner will acquire the lock with an error value ofEOWNERDEAD.
The memory for the object to be initialized with this attribute must be zeroed before initialization. Any thread or process interested in the robust lock can callmutex_init() to potentially initialize it, provided that all such callers ofmutex_init() specify the same set of attribute flags. In this situation, ifmutex_init() is called on a previously initialized robust mutex,mutex_init() will not reinitialize the mutex and will return the error valueEBUSY.
A thread attempting to relock this mutex without first unlocking it will succeed in locking the mutex. The mutex must be unlocked as many times as it is locked.
UnlessLOCK_RECURSIVE is also set, a thread attempting to relock this mutex without first unlocking it will return with an error rather than deadlocking itself. A thread attempting to unlock this mutex without first owning it will return with an error.
When a thread is blocking higher priority threads because of owning one or more mutexes with theLOCK_PRIO_INHERIT attribute, it executes at the higher of its priority or the priority of the highest priority thread waiting on any of the mutexes owned by this thread and initialized with this attribute.
When a thread owns one or more mutexes initialized with theLOCK_PRIO_PROTECT attribute, it executes at the higher of its priority or the highest of the priority ceilings of all the mutexes owned by this thread and initialized with this attribute, regardless of whether other threads are blocked on any of these mutexes. When this attribute is specified,arg must point to anint containing the priority ceiling.
Seepthread_mutexattr_getrobust(3C) for more information about robust mutexes. TheLOCK_ROBUST attribute isthe same as the POSIXPTHREAD_MUTEX_ROBUST attribute.
Seepthread_mutexattr_settype(3C) for more information on recursive and error checking mutex types.The combination (LOCK_RECURSIVE |LOCK_ERRORCHECK) is the same as the POSIXPTHREAD_MUTEX_RECURSIVEtype. By itself,LOCK_ERRORCHECK is the same as thePOSIX PTHREAD_MUTEX_ERRORCHECK type.
TheLOCK_PRIO_INHERIT attribute is the same as the POSIXPTHREAD_PRIO_INHERIT attribute. TheLOCK_PRIO_PROTECT attribute is the same as the POSIXPTHREAD_PRIO_PROTECT attribute. Seepthread_mutexattr_getprotocol(3C),pthread_mutexattr_getprioceiling(3C), andpthread_mutex_getprioceiling(3C) for a full discussion. TheLOCK_PRIO_INHERIT andLOCK_PRIO_PROTECT attributesare mutually exclusive. Specifying both of these attributes causesmutex_init() to failwithEINVAL.
Initializing mutexes can also be accomplished by allocating in zeroed memory(default), in which case atype ofUSYNC_THREAD is assumed. In general,the following rules apply to mutex initialization:
The same mutex must not be simultaneously initialized by multiple threads.
A mutex lock must not be reinitialized while in use by other threads.
These rules do not apply toLOCK_ROBUST mutexes. See the description forLOCK_ROBUSTabove. If default mutex attributes are used, the macroDEFAULTMUTEX can beused to initialize mutexes that are statically allocated.
Default mutex initialization (intra-process):
mutex_t mp;mutex_init(&mp, USYNC_THREAD, NULL);
or
mutex_t mp = DEFAULTMUTEX;
Customized mutex initialization (inter-process):
mutex_init(&mp, USYNC_PROCESS, NULL);
Customized mutex initialization (inter-process robust):
mutex_init(&mp, USYNC_PROCESS | LOCK_ROBUST, NULL);
Statically allocated mutexes can also be initialized with macros specifyingLOCK_RECURSIVE and/orLOCK_ERRORCHECK:
Same as (USYNC_THREAD |LOCK_RECURSIVE)
Same as (USYNC_THREAD |LOCK_ERRORCHECK)
Same as (USYNC_THREAD |LOCK_RECURSIVE |LOCK_ERRORCHECK)
A critical section of code is enclosed by a the callto lock the mutex and the call to unlock the mutex toprotect it from simultaneous access by multiple threads. Only one thread ata time may possess mutually exclusive access to the critical sectionof code that is enclosed by the mutex-locking call and the mutex-unlocking call,whether the mutex's scope is intra-process or inter-process. A thread callingto lock the mutex either gets exclusive access to the codestarting from the successful locking until its call to unlock the mutex,or it waits until the mutex is unlocked by the thread that lockedit.
Mutexes have ownership, unlike semaphores. Although any thread, within the scope ofa mutex, can get an unlocked mutex and lock access to thesame critical section of code, only the thread that locked a mutexshould 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. A mutex protects code, not data; therefore,strongly bind a mutex with the data by putting both withinthe same structure, or at least within the same procedure.
A call tomutex_lock() locks the mutex object referenced bymp. Ifthe mutex is already locked, the calling thread blocks until the mutexis freed; this will return with the mutex object referenced bympin the locked state with the calling thread as its owner. If thecurrent owner of a mutex tries to relock the mutex, it willresult in deadlock.
Themutex_trylock() function is the same asmutex_lock(), respectively, except that ifthe mutex object referenced bymp is locked (by any thread, includingthe current thread), the call returns immediately with an error.
Themutex_unlock() function are called by the owner of the mutex objectreferenced bymp to release it. The mutex must be locked andthe calling thread must be the one that last locked the mutex(the owner). If there are threads blocked on the mutex object referenced bymp whenmutex_unlock() is called, themp is freed, and the schedulingpolicy will determine which thread gets the mutex. If the calling threadis not the owner of the lock, no error status is returned, andthe behavior of the program is undefined.
Themutex_destroy() function destroys the mutex object referenced bymp. The mutexobject becomes uninitialized. The space used by the destroyed mutex variable isnot freed. It needs to be explicitly reclaimed.
If successful, these functions return0. Otherwise, an error number is returned.
Themutex_init() function will fail if:
The value specified bytype is invalid, or theLOCK_PRIO_INHERIT andLOCK_PRIO_PROTECT attributes are both specified.
Themutex_init() function will fail forLOCK_ROBUST type mutex if:
The mutex pointed to bymp was previously initialized and has not yet been destroyed.
The mutex pointed to bymp was previously initialized with a different set of attribute flags.
Themutex_trylock() function will fail if:
The mutex pointed to bymp is already locked.
Themutex_lock() andmutex_trylock() functions will fail for aLOCK_RECURSIVE mutex if:
The mutex could not be acquired because the maximum number of recursive locks for the mutex has been reached.
Themutex_lock() function will fail for aLOCK_ERRORCHECK and non-LOCK_RECURSIVE mutex if:
The caller already owns the mutex.
Themutex_lock() function may fail for a non-LOCK_ERRORCHECK and non-LOCK_RECURSIVE mutex if:
The caller already owns the mutex.
Themutex_unlock() function will fail for aLOCK_ERRORCHECK mutex if:
The caller does not own the mutex.
Themutex_lock() ormutex_trylock() functions will fail forLOCK_ROBUST type mutexif:
The last owner of this mutex died while holding the mutex. This mutex is now owned by the caller. The caller must now attempt to make the state protected by the mutex consistent. If it is able to clean up the state, then it should restore the state of the mutex by callingmutex_consistent() and unlock the mutex. Subsequent calls tomutex_lock() will behave normally, as before. If the caller is not able to clean up the state,mutex_consistent() should not be called but the mutex should be unlocked. Subsequent calls tomutex_lock() will fail to acquire the mutex, returning with the error valueENOTRECOVERABLE. If the owner who acquired the lock withEOWNERDEAD dies, the next owner will acquire the lock withEOWNERDEAD.
The mutex trying to be acquired was protecting the state that has been left unrecoverable when the mutex's last owner could not make the state protected by the mutex consistent. The mutex has not been acquired. This condition occurs when the lock was previously acquired withEOWNERDEAD and the owner was not able to clean up the state and unlocked the mutex without callingmutex_consistent().
Themutex_consistent() function will fail if:
The caller does not own the mutex or the mutex is not aLOCK_ROBUST mutex having an inconsistent state (EOWNERDEAD).
The following example uses one global mutex as a gate-keeper to permiteach thread exclusive sequential access to the code within the user-defined function “change_global_data.” This type of synchronization will protect the state of shareddata, but it also prohibits parallelism.
/* cc thisfile.c -lthread */#define _REENTRANT#include <stdio.h>#include <thread.h>#define NUM_THREADS 12void *change_global_data(void *); /* for thr_create() */main(int argc,char * argv[]) { int i=0; for (i=0; i< NUM_THREADS; i++) { thr_create(NULL, 0, change_global_data, NULL, 0, NULL); } while ((thr_join(NULL, NULL, NULL) == 0));}void * change_global_data(void *null){ static mutex_t Global_mutex; static int Global_data = 0; mutex_lock(&Global_mutex); Global_data++; sleep(1); printf("%d is global data\n",Global_data); mutex_unlock(&Global_mutex); return NULL;}The previous example, the mutex, the code it owns, and the datait protects was enclosed in one function. The next example uses C++features to accommodate many functions that use just one mutex to protectone data:
/* CC thisfile.c -lthread use C++ to compile*/#define _REENTRANT#include <stdlib.h>#include <stdio.h>#include <thread.h>#include <errno.h>#include <iostream.h>#define NUM_THREADS 16void *change_global_data(void *); /* for thr_create() */class Mutected { private: static mutex_t Global_mutex; static int Global_data; public: static int add_to_global_data(void); static int subtract_from_global_data(void);};int Mutected::Global_data = 0;mutex_t Mutected::Global_mutex;int Mutected::add_to_global_data() { mutex_lock(&Global_mutex); Global_data++; mutex_unlock(&Global_mutex); return Global_data;}int Mutected::subtract_from_global_data() { mutex_lock(&Global_mutex); Global_data--; mutex_unlock(&Global_mutex); return Global_data;}voidmain(int argc,char * argv[]) { int i=0; for (i=0;i< NUM_THREADS;i++) { thr_create(NULL,0,change_global_data,NULL,0,NULL); } while ((thr_join(NULL,NULL,NULL) == 0));}void * change_global_data(void *) { static int switcher = 0; if ((switcher++ % 3) == 0) /* one-in-three threads subtracts */ cout << Mutected::subtract_from_global_data() << endl; else cout << Mutected::add_to_global_data() << endl; return NULL;}A mutex can protect data that is shared among processes. The mutexwould need to be initialized asUSYNC_PROCESS. One process initializes theprocess-shared mutex and writes it to a file to be mappedinto memory by all cooperating processes (seemmap(2)). Afterwards, other independent processescan run the same program (whether concurrently or not) and share mutex-protecteddata.
/* cc thisfile.c -lthread *//* To execute, run the command line "a.out 0 &; a.out 1" */#define _REENTRANT#include <sys/types.h>#include <sys/mman.h>#include <sys/stat.h>#include <fcntl.h>#include <stdio.h>#include <thread.h>#define INTERPROCESS_FILE "ipc-sharedfile"#define NUM_ADDTHREADS 12#define NUM_SUBTRACTTHREADS 10#define INCREMENT '0'#define DECREMENT '1'typedef struct { mutex_t Interprocess_mutex; int Interprocess_data;} buffer_t;buffer_t *buffer;void *add_interprocess_data(), *subtract_interprocess_data();void create_shared_memory(), test_argv();int zeroed[sizeof(buffer_t)];int ipc_fd, i=0;voidmain(int argc,char * argv[]){ test_argv(argv[1]); switch (*argv[1]) { case INCREMENT: /* Initializes the process-shared mutex */ /* Should be run prior to running a DECREMENT process */ create_shared_memory(); ipc_fd = open(INTERPROCESS_FILE, O_RDWR); buffer = (buffer_t *)mmap(NULL, sizeof(buffer_t), PROT_READ | PROT_WRITE, MAP_SHARED, ipc_fd, 0); buffer->Interprocess_data = 0; mutex_init(&buffer->Interprocess_mutex, USYNC_PROCESS,0); for (i=0; i< NUM_ADDTHREADS; i++) thr_create(NULL, 0, add_interprocess_data, argv[1], 0, NULL); break; case DECREMENT: /* Should be run after the INCREMENT process has run. */ while(ipc_fd = open(INTERPROCESS_FILE, O_RDWR)) == -1) sleep(1); buffer = (buffer_t *)mmap(NULL, sizeof(buffer_t), PROT_READ | PROT_WRITE, MAP_SHARED, ipc_fd, 0); for (i=0; i< NUM_SUBTRACTTHREADS; i++) thr_create(NULL, 0, subtract_interprocess_data, argv[1], 0, NULL); break; } /* end switch */ while ((thr_join(NULL,NULL,NULL) == 0));} /* end main */void *add_interprocess_data(char argv_1[]){ mutex_lock(&buffer->Interprocess_mutex); buffer->Interprocess_data++; sleep(2); printf("%d is add-interprocess data, and %c is argv1\n", buffer->Interprocess_data, argv_1[0]); mutex_unlock(&buffer->Interprocess_mutex); return NULL;}void *subtract_interprocess_data(char argv_1[]) { mutex_lock(&buffer->Interprocess_mutex); buffer->Interprocess_data--; sleep(2); printf("%d is subtract-interprocess data, and %c is argv1\n", buffer->Interprocess_data, argv_1[0]); mutex_unlock(&buffer->Interprocess_mutex); return NULL;}void create_shared_memory(){ int i; ipc_fd = creat(INTERPROCESS_FILE, O_CREAT | O_RDWR ); for (i=0; i<sizeof(buffer_t); i++){ zeroed[i] = 0; write(ipc_fd, &zeroed[i],2); } close(ipc_fd); chmod(INTERPROCESS_FILE, S_IRWXU | S_IRWXG | S_IRWXO);}void test_argv(char argv1[]) { if (argv1 == NULL) { printf("use 0 as arg1 for initial process\n \ or use 1 as arg1 for the second process\n"); exit(NULL); }}A mutex can protect data that is shared among processes robustly. Themutex would need to be initialized asUSYNC_PROCESS |LOCK_ROBUST. One processinitializes the robust process-shared mutex and writes it to a file tobe mapped into memory by all cooperating processes (seemmap(2)). Afterwards, other independentprocesses can run the same program (whether concurrently or not) and sharemutex-protected data.
The following example shows how to use aUSYNC_PROCESS |LOCK_ROBUST typemutex.
/* cc thisfile.c -lthread */ /* To execute, run the command line "a.out & a.out 1" */ #include <sys/types.h> #include <sys/mman.h> #include <fcntl.h> #include <stdio.h> #include <thread.h> #define INTERPROCESS_FILE "ipc-sharedfile" typedef struct { mutex_t Interprocess_mutex; int Interprocess_data; } buffer_t; buffer_t *buffer; int make_date_consistent(); void create_shared_memory(); int zeroed[sizeof(buffer_t)]; int ipc_fd, i=0; main(int argc,char * argv[]) { int rc; if (argc > 1) { while((ipc_fd = open(INTERPROCESS_FILE, O_RDWR)) == -1) sleep(1); buffer = (buffer_t *)mmap(NULL, sizeof(buffer_t), PROT_READ | PROT_WRITE, MAP_SHARED, ipc_fd, 0); mutex_init(&buffer->Interprocess_mutex, USYNC_PROCESS | LOCK_ROBUST,0); } else { create_shared_memory(); ipc_fd = open(INTERPROCESS_FILE, O_RDWR); buffer = (buffer_t *)mmap(NULL, sizeof(buffer_t), PROT_READ | PROT_WRITE, MAP_SHARED, ipc_fd, 0); buffer->Interprocess_data = 0; mutex_init(&buffer->Interprocess_mutex, USYNC_PROCESS | LOCK_ROBUST,0); } for(;;) { rc = mutex_lock(&buffer->Interprocess_mutex); switch (rc) { case EOWNERDEAD: /* * The lock is acquired. * The last owner died holding the lock. * Try to make the state associated with * the mutex consistent. * If successful, make the robust lock consistent. */ if (make_data_consistent()) mutex_consistent(&buffer->Interprocess_mutex); mutex_unlock(&buffer->Interprocess_mutex); break; case ENOTRECOVERABLE: /* * The lock is not acquired. * The last owner got the mutex with EOWNERDEAD * and failed to make the data consistent. * There is no way to recover, so just exit. */ exit(1); case 0: /* * There is no error - data is consistent. * Do something with data. */ mutex_unlock(&buffer->Interprocess_mutex); break; } }} /* end main */void create_shared_memory() { int i; ipc_fd = creat(INTERPROCESS_FILE, O_CREAT | O_RDWR ); for (i=0; i<sizeof(buffer_t); i++) { zeroed[i] = 0; write(ipc_fd, &zeroed[i],2); } close(ipc_fd); chmod(INTERPROCESS_FILE, S_IRWXU | S_IRWXG | S_IRWXO); } /* return 1 if able to make data consistent, otherwise 0. */ int make_data_consistent () { buffer->Interprocess_data = 0; return (1); }The following example allocates and frees memory in which a mutex isembedded.
struct record { int field1; int field2; mutex_t m;} *r;r = malloc(sizeof(struct record));mutex_init(&r->m, USYNC_THREAD, NULL);/* * The fields in this record are accessed concurrently * by acquiring the embedded lock. */The thread execution in this example is as follows:
Thread 1 executes:Thread 2 executes:... ...mutex_lock(&r->m); mutex_lock(&r->m);r->field1++; localvar = r->field1;mutex_unlock(&r->m); mutex_unlock(&r->m);... ...
Later, when a thread decides to free the memory pointed to byr, the thread should callmutex_destroy( ) on the mutexesin this memory.
In the following example, the main thread can do athr_join( )on both of the above threads. If there are no other threadsusing the memory inr, the main thread can now safelyfreer:
for (i = 0; i < 2; i++) thr_join(0, 0, 0);mutex_destroy(&r->m); /* first destroy mutex */free(r); /* then free memory */
If the mutex is not destroyed, the program could have memory leaks.
Seeattributes(5) for descriptions of the following attributes:
|
mmap(2),shmop(2),pthread_mutexattr_getprioceiling(3C),pthread_mutexattr_getprotocol(3C),pthread_mutexattr_getrobust(3C),pthread_mutexattr_gettype(3C),pthread_mutex_getprioceiling(3C),pthread_mutex_init(3C),attributes(5),mutex(5),standards(5)
Previous releases of Solaris provided theUSYNC_PROCESS_ROBUST mutex type. This type isnow deprecated but is still supported for source and binary compatibility. Whenpassed tomutex_init(), it is transformed into (USYNC_PROCESS |LOCK_ROBUST). The formermethod for restoring aUSYNC_PROCESS_ROBUST mutex to a consistent state was toreinitialize it by callingmutex_init(). This method is still supported for sourceand binary compatibility, but the proper method is to callmutex_consistent().
TheUSYNC_PROCESS_ROBUST type permitted an alternate error value,ELOCKUNMAPPED, to be returnedbymutex_lock() if the process containing a locked robust mutex unmapped thememory containing the mutex or performed one of theexec(2) functions. TheELOCKUNMAPPED error value implies all of the consequences of theEOWNERDEAD errorvalue and as such is just a synonym forEOWNERDEAD. For full sourceand binary compatibility, theELOCKUNMAPPED error value is still returned frommutex_lock()in these circumstances, but only if the mutex was initialized with theUSYNC_PROCESS_ROBUST type. Otherwise,EOWNERDEAD is returned in these circumstances.
Themutex_lock(),mutex_unlock(), andmutex_trylock() functions do not validate the mutex type.An uninitialized mutex or a mutex with an invalid type does notreturnEINVAL. Interfaces for mutexes with an invalid type have unspecified behavior.
Uninitialized mutexes that are allocated locally could contain junk data. Such mutexesneed to be initialized usingmutex_init().
By default, if multiple threads are waiting for a mutex, the orderof acquisition is undefined.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.Legal Notices |   |