![]() |
![]() |
| ||||||||
Create a Thread-Specific Data KeyExcept for the function names and arguments, thread specific data is the same for Solaris as it is for POSIX. The synopses for the Solaris functions are given in this section. thr_keycreate(3THR)thr_keycreate(3THR) allocates a key that is used to identify thread-specific data in a process. (For POSIX threads, see pthread_key_create(3THR).)
Set Thread-Specific Datathr_setspecific(3THR)thr_setspecific(3THR) binds value to the thread-specific data key, key, for the calling thread. (For POSIX threads, see pthread_setspecific(3THR).)
Get Thread-Specific Datathr_getspecific(3THR)thr_getspecific(3THR) stores the current value bound to key for the calling thread into the location pointed to by valuep. (For POSIX threads, see pthread_getspecific(3THR).)
Set the Thread PriorityIn Solaris threads, if a thread is to be created with a priority other than that of its parent's, it is created in SUSPEND mode. While suspended, the threads priority is modified using the thr_setprio(3THR) function call; then it is continued. A higher priority thread will receive precedence by libthread over lower priority threads with respect to synchronization object contention. thr_setprio(3THR)thr_setprio(3THR) changes the priority of the thread, specified by tid, within the current process to the priority specified by newprio. (For POSIX threads, see pthread_setschedparam(3THR).)
By default, threads are scheduled based on fixed priorities that range from zero, the least significant, to 127 the most significant.
Get the Thread Prioritythr_getprio(3THR)Use thr_getprio(3THR) to get the current priority for the thread. Each thread inherits a priority from its creator. thr_getprio() stores the current priority, tid, in the location pointed to by newprio. (For POSIX threads, see pthread_getschedparam(3THR).)
Similar Synchronization Functions--Mutual Exclusion LocksInitialize a Mutexmutex_init(3THR)
Use mutex_init(3THR) to initialize the mutex pointed to by mp. The type can be one of the following (note that arg is currently ignored). (For POSIX threads, see Initialize a Mutex.)
When a process dies while holding a USYNC_PROCESS lock, subsequent requestors of that lock hang. This is a problem for systems which share locks with client processes because the client processes can be abnormally killed. To avoid the problem of hanging on a lock held by a dead process, use USYNC_PROCESS_ROBUST to lock the mutex. USYNC_PROCESS_ROBUST adds two capabilities:
Mutexes can also be initialized by allocation in zeroed memory, in which case a type of USYNC_THREAD is assumed. Multiple threads must not initialize the same mutex simultaneously. A mutex lock must not be reinitialized while other threads might be using it. Mutexes With Intraprocess Scope
| ||||||||
| ||||||||