S_IRUSR | user read permission |
S_IWUSR | user write permission |
S_IRGRP | group read permission |
S_IWGRP | group write permission |
S_IROTH | other read permission |
S_WOTH | other write permission |
The initialValue argument is the semaphore’s initial count value. It cannot be greater than the defined constant SEM_VALUE_MAX.
To close a semaphore, use the function
int sem_close(sem_t *sem);
To remove a semaphore from the file system, use the function
int sem_unlink(const char *name);
From here, POSIX semaphores behave, at least conceptually, in a way similar to Win32 semaphores. The semaphore’s count value is incremented when the resource it guards becomes available, and decremented when a thread has been granted access to the resource. Four functions are used to manage a semaphore:
int sem_wait(sem_t *sem);int sem_trywait(sem_t *sem);int sem_post(sem_t *sem);int sem_getvalue(sem_t *sem, int *value);
All four functions return 0 on success, or -1 if an error occurs.
The sem_wait function blocks the caller until the count value is greater than zero. Then, the caller is released and the count value is decremented. You can use the sem_trywait function to test the count value. The sem_trywait function does not block the caller. Instead it immediately returns a value of EAGAIN if the value is currently zero.
To increment the value of a semaphore, you call the sem_post function. One difference between a semaphore and a mutex is that a thread acquiring a semaphore with sem_wait or sem_trywait need not be the same thread that increments the value with sem_post. A mutex must be locked and unlocked by the same thread.
Another important feature of semaphores is that a thread can call the sem_post function at any time, regardless of whether there are other threads waiting in a sem_wait call. The fact that the semaphore’s value was incremented is retained, even if there are no waiting threads. Contrast this with condition variables, where the fact that the condition is signaled is lost if there are no waiting threads. Condition variables are discussed in the section Using pthreads Condition Variables.
Using Pthreads Condition Variables
A condition variable is used by a thread to suspend its own execution until an expression involving shared data reaches a desired state. The Win32 multithreading API does not have a native implementation of condition variables. There have been many implementations of the condition variable model using available Win32 synchronization tools such as events. The pthreads library contains a native implementation of condition variables. While condition variables are still complex in nature, the fact that they are supported natively in the library could help you simplify difficult synchronization code.
A pthreads condition variable is always used in conjunction with a mutex. When you need to make a thread wait on a condition variable, you must first lock the mutex, and then wait on the condition variable. The flow of events is as follows:
- Thread A needs to wait on the condition variable. It locks the mutex associated with the condition variable with
pthread_mutex_lock. - Thread A calls
pthread_cond_wait, which takes the condition variable and its associated mutex as parameters. Thepthread_cond_waitfunction releases the associated mutex so that other threads can lock it and change the shared data. Thread A is now waiting until the condition variable has been signaled by another thread. - Thread B needs to change the value of the shared data. It locks the associated mutex and makes the change.
- Thread B signals thread A by calling the
pthread_cond_signalfunction. Thread B could also signal all waiting threads by callingpthread_cond_broadcast. - After signaling, thread B releases the associated mutex with
pthread_mutex_unlock. - Thread A “wakes up” from the
pthread_cond_waitcall. Upon return frompthread_cond_wait, the associated mutex has been locked on thread A’s behalf (by the pthread library), so that the shared data can be safely examined.
When a thread waiting on a condition variable wakes up, it should immediately check the shared data to be sure it is in the required state. This seems redundant at first glance but it is necessary for three reasons:
- In the case where multiple threads are waiting on the same condition variable, it’s possible that another thread was scheduled to run first, and has already changed the shared data.
This is difficult to grasp at first, but recall that there are two parts to a condition variable: the condition variable itself, and its associated mutex.
When a condition variable is signaled, its associated mutex must be reacquired by the library. When multiple threads are waiting, the library uses the threads’ scheduling priority to determine which thread will be granted the mutex lock. Other threads are then put into a queue of threads that are waiting to acquire the mutex. Therefore, just because our thread wakes up when the condition variable is signaled, it does not mean it was the first to reacquire the mutex.
- It’s always possible that the condition was signaled in error, due to a logic bug in the signaling thread.
- The pthread standard does not prohibit the underlying threading implementation from waking up a waiting thread.
Like mutex variables, condition variables can be created and initialized either statically or dynamically. The following code statically initializes a condition variable:
pthread_cond_t myConditionVariable; myConditionVariable = PTHREAD_COND_INITIALIZER;
To dynamically create and initialize a condition variable, you use the pthread_cond_init function. If you want to assign custom attributes to the condition variable, use the pthread_condattr_init, and related functions. The pthread_condattr_init function takes the address of a pthread_condattr_t variable:
int pthread_condattr_init(pthread_condattr_t *attr);
There is only one condition variable attribute, which governs whether or not the variable can be used by threads in other processes. The functions
int pthread_condattr_setpshared(pthread_condattr *attr, int pshared);int pthread_condattr_getpshared(pthread_condattr *attr, int *pshared);
set and retrieve the attribute, respectively. The pshared parameter has the value PTHREAD_PROCESS_SHARED, or PTHREAD_PROCESS_PRIVATE.
You pass the attribute variable to the pthread_cond_init function.
int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *attr);
To accept default condition variable attribute settings, pass a NULL value to pthread_cond_init.
There are two functions for waiting on a condition variable:
int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);
The timedwait function allows you to specify the number of seconds to wait in a timespec structure (defined in time.h).
Two functions allow for signaling one thread, or all waiting threads, respectively:
int pthread_cond_signal(pthread_cond_t *cond);
int pthread_cond_broadcast(pthread_cond_t *cond);
When you are finished using a condition variable, call pthread_cond_destroy:
int pthread_cond_destroy(pthread_cond_t *cond);
This will delete the condition variable so that it cannot be used again in any pthread_cond function.
Using pthread_join
To suspend execution of one thread until another thread terminates, you can call the Win32 WaitForSingleObject with the thread’s handle. When the thread exits, its handle becomes signaled and WaitForSingleObject returns.
The pthread equivalent is the pthread_join function. pthread_join waits for the specified thread to exit. The thread’s exit code is retrieved through a parameter passed to pthread_join. The signature of pthread_join is:
int pthread_join(pthread_t thread, void **value_ptr);
Retrieving the thread’s return value is discussed in the section Handling Thread Termination in pthreads.
Thread Synchronization with Carbon Multiprocessing
The Carbon Multiprocessing thread package provides four ways to synchronize access to shared data:
- Critical regions
- Message notification queues
- Semaphores
- Events (called event groups)
Carbon Critical Regions
The four Carbon functions for handling critical regions are:
OSStatus MPCreateCriticalRegion(MPCriticalRegionID *criticalRegion);OSStatus MPDeleteCriticalRegion(MPCriticalRegionID criticalRegion);OSStatus MPEnterCriticalRegion(MPCriticalRegionID criticalRegion, Duration timeout);OSStatus MPExitCriticalRegion(MPCriticalRegionID criticalRegion);
These functions map to the Win32 functions, InitializeCriticalSection, DeleteCriticalSection, EnterCriticalSection, and LeaveCriticalSecion, respectively.
The MPEnterCriticalRegion function allows you to specify a timeout value. Using a timeout value of kDurationImmediate results in behavior similar to the Win32 function TryEnterCriticalSection, See the topic Timer Duration Constants for information on how to use the timeout parameter.
As on Win32, the critical region entry function can be called multiple times from within the critical section. Each call to MPEnterCriticalRegion must be balanced with a corresponding call to MPExitCriticalRegion.
Carbon Multiprocessing Message Notification Queues
Carbon applications can use notification queues as a simple way to pass messages between threads. A message consists of three 32-bit values, which are not interpreted by the system. Their meaning is completely programmer-defined and any or all of the three values can actually be NULL.
The Carbon functions for creating and managing notification queues are shown in this article in the sections Carbon Multiprocessing Notification Queues, and Handling Thread Termination in Carbon Mulitprocessing Services. Still more information on message notification queues can be found in the Carbon Reference Library topic, Creating and Handling Message Queues.
Carbon Multiprocessing Semaphores
The Carbon multiprocessing semaphore functions are quite similar to their Win32 counterparts. When you create the semaphore, you specify the maximum and initial count values, just as you do on Win32. The four Carbon Multiprocessing semaphore functions are:
OSStatus MPCreateSemaphore(MPSemaphoreCount maximumValue, MPSemaphoreCount initialValue, MPSemaphoreID *semaphore);OSStatus MPDeleteSemaphore(MPSemaphore ID semaphore);OSStatus MPSignalSemaphore(MPSemaphoreID semaphore);OSStatus MPWaitOnSemaphore(MPSemaphoreID semaphore, Duration timeout);
Like the Win32 ReleaseSemaphore function, Carbon’s MPSignalSemaphore increases the semaphore’s count value by one and unblocks the oldest thread waiting in a call to MPWaitOnSemaphore. When a call to MPWaitOnSemaphore completes without timing out, the semaphore’s count is decremented by one. The thread can then proceed, and when access to the semaphore is no longer needed it calls MPSignalSemaphore.
When the semaphore’s count reaches zero, a thread that calls MPWaitOnSemaphore will be blocked until the semaphore’s count is again greater than zero, and the thread is at the head of the queue of waiting threads. The timeout argument allows you to wait indefinitely, wait for a finite period of time, or to not wait at all (i.e. test the semaphore’s count without blocking). See the topic Timer Duration Constants for information on how to use the timeout parameter.
Carbon applications can use the macro
MPCreateBinarySemaphore(MPSemaphoreID *semaphore)
to create a binary semaphore, which behaves like a mutex. The macro expands to a call to MPCreateSemaphore, creating a semaphore with its maximum and initial values both set to one.
Carbon Multiprocessing Event Groups
A Carbon event group is conceptually similar to an auto-reset event in Win32. An event group has the type MPEventFlags, and is an aggregate of individual, 1-bit flags. The flags in an event group are simply binary values indicating whether the event has occurred or not.
The four Carbon functions for creating and managing event groups are:
OSStatus MPCreateEvent(MPEventID *event);OSStatus MPDeleteEvent(MPEventID event);OSStatus MPSetEvent(MPEventID event, MPEventFlags flags);OSStatus MPWaitForEvent(MPEventID event, MPEventFlags *flags, Duration timeout);
On Win32, the SetEvent function puts an event handle into a signaled state. The Carbon MPSetEvent function is similar, except with it you can indicate the occurrence of multiple events. You do this by setting bits in the flags parameter. Calling MPSetEvent causes the flags to be logically OR’d with the current flags in the event group.
Threads wait for event flags to be set by calling the MPWaitForEvent function. When MPWaitForEvent returns without timing out, all of the flags comprising the event group are returned in their current state (there is no way to poll for individual flags). All of the flags are then cleared, similar to an auto-reset event on Win32. As with Carbon semaphores, multiple threads waiting on an event group are queued in first in, first out order. When flags are set with MPSetEvent, the first (i.e. the oldest) waiting thread in the queue is unblocked.
The timeout argument of the MPWaitForEvent function allows you to wait indefinitely, or for a finite amount of time. You can also test the state of the event group without blocking. See the topic Timer Duration Constants for information on how to use the timeout parameter.
Thread Synchronization with Cocoa Threads
The thread synchronization tools offered by Cocoa are limited compared to those of pthreads and Carbon Multiprocessing. As a tradeoff, they offer much more in the way of automatically managed attributes and are therefore much easier to use. Cocoa offers two synchronization classes: NSLock, and NSConditionLock.
Using the NSLock Class
The NSLock class adopts (implements) the NSLocking protocol, which contains two methods, lock and unlock. To use the class, simply allocate and initialize an instance, and then surround the block of code you wish to protect with lock and unlock calls, as illustrated here:
NSLock *myLock; myLock = [[NSLock alloc] init]; [mylock lock]; // protected code here [mylock unlock];
The NSLock class contains two additional methods, lockBeforeDate, and tryLock. The lockBeforeDate method accepts an NSDate object and will timeout if the lock cannot be acquired before the specified date and time.
The tryLock method can be used to test the state of a lock. The method returns immediately with a value of YES or NO, depending on whether the lock was acquired. If tryLock returns a value of YES, the lock was acquired and you must follow up with a call to unlock to release it.
Using the Objective-C @synchronized Directive
If you require a simple Win32-style critical section, you don’t have to dig into the NSLock class at all. The Objective-C language has a directive called @synchronized that you can use instead.
The @synchronized directive takes one parameter, which can be any Objective-C object (i.e. it is of type id). The parameter is the object you wish to have exclusive access to in the code block protected by the directive. The @synchronized directive introduces a code block, as shown in the following example:
-(void) aMethod:(id)anObject{ @synchronized(anObject) // Exclusive access to anObject requested here... { // Exclusive access to anObject has been granted... [anObject modify]; } // Exclusive access to anObject relinquished here.}The mutex associated with the block is automatically released on exit from the code block.
For more information on the @synchronized directive, see Synchronizing Thread Execution in The Objective-C Programming Language.
Using the NSConditionLock Class
The NSConditionLock class implements a notification mechanism somewhat similar to a Win32 manual-reset event. The class contains methods that let you synchronize participating threads by waiting and locking when user-defined conditions are met.
User-defined conditions are integers, and the NSConditionLock class contains methods such as initWithCondition and lockWhenCondition to initialize the lock in a particular state, and to wait on the lock until the given condition is achieved. After acquiring an NSConditionLock, you can use the unlockWithCondition method to release the lock in a new state. Other threads waiting on the lock with the lockWhenCondition method will then be awakened.
The NSConditionLock class is essentially a pthreads condition variable with the condition test always being of the form:
(condition == value)
where condition is the current value of the lock, and value is the user-defined state you are waiting for. The value is passed as a parameter to the lockWhenCondition method.
Thread Termination
Thread Termination on Win32
When a thread function completes, its status code is returned by either:
- Directly returning a value of type
DWORDfrom the thread function - Calling the
ExitThreadfunction with the thread’s status code
To retrieve the thread’s status code, you use the GetExitCodeThread function.
In the most extreme cases, you can use the TerminateThread function to stop a thread with no questions asked.
These exit strategies map closely to both the pthreads and Carbon Multiprocessing APIs. The Cocoa threading classes behave a bit differently. These differences will be discussed below.
Handling Thread Termination in pthreads
Conceptually, returning the exit status of a thread is exactly the same in the pthreads library as it is on Win32. You can either:
- Return a value of type
void *directly from the thread function - Call the
pthread_exitfunction with the thread’s status code
Retrieving the thread’s status code however, is handled a little bit differently. In the pthreads library, a thread is said to be either joinable, or detached.
A joinable thread is one whose thread identifier can be passed to the pthread_join function. The pthread_join function waits for the specified thread to terminate. It also takes a parameter in which the library will store the thread’s status code. By default, a thread is joinable when it is created.
A detached thread cannot be used in a call to pthread_join, and therefore it has no return status code. There are two ways to create a detached thread:
- Specifying thread attributes when you call
pthread_create - Calling the
pthread_detachfunction after the thread has been created
You can return integral values from a thread, as long as your status codes do not conflict with the reserved value PTHREAD_CANCELED. Of course, you will also have to cast those values to their appropriate types, as the status code is a void * as far as pthreads is concerned. Note that avoiding the PTHREAD_CANCELED value is a problem similar to the mistake of accidentally returning the reserved STILL_ACTIVE value on Win32.
Canceling a Thread in pthreads
As on Win32, terminating a thread prematurely is fraught with peril. You should always try to structure your code so this case can be avoided. This article will not cover thread cancelation in great detail. Suffice it to say that the pthreads library gives the thread itself substantial control over its own cancelation. Indeed, a thread can elect to make itself not be cancelable at all. A thread can even switch in and out of a cancelable state as it runs.
n the pthreads library, threads have both a cancellation state, and a cancellation type. The cancellation state determines whether the tread can be cancelled or not. It can take the values:
PTHREAD_CANCEL_DISABLEPTHREAD_CANCEL_ENABLE
You set the cancellation state with the function
int pthread_setcancelstate(int state, int *oldstate);
The thread’s cancellation type determines when the thread can be canceled. It can take the values:
PTHREAD_CANCEL_ASYNCHRONOUSPTHREAD_CANCEL_DEFERRED
The cancellation type is set by the function
int pthread_setcanceltype(int type, int *oldtype);
By default a thread is cancelable, and its cancellation type is set to PTHREAD_CANCEL_DEFERRED.
The asynchronous cancellation type means the thread can be cancelled at any point in its execution. The usual red flags and warnings apply in the pthreads library; terminating a thread can wreak havoc with other threads in the process. The pthreads library does give you a way to specify cleanup routines, which are run when a thread is cancelled. This will be discussed shortly.
The deferred cancellation type means the thread can only be cancelled when it is at a certain point in its execution. There are two types of cancellation points:
- Automatic
There are three automatic cancellation points:
pthread_cond_waitpthread_cond_timedwaitpthread_joinThe thread can be cancelled while it is blocked in any of these three functions.
- Programmer-defined
A programmer-defined cancellation point is inserted with the function
pthread_testcancel. The call has no effect if there is no cancellation request pending. You can insert a call topthread_testcancelat any point in the code where a termination is safe, such as prior to acquiring a lock or before a lengthy operation.
Thread Cleanup Stacks
Cleanup stacks give each thread a chance to execute a set of final routines when it is terminated. You add a function to the thread’s cleanup stack with the function
void pthread_cleanup_push(void (*routine)(void *), void *arg);
The signature of a cleanup routine is
void cleanupRoutine(void *);
The arg parameter of pthread_cleanup_push will be passed to the cleanup function.
Cleanup functions are executed in last-in-first-out order, as implied. Note that cleanup routines are executed even when a thread exits cleanly with pthread_exit.
The pthread standard requires that every call to pthread_cleanup_push within a lexical scope be paired with a corresponding call to the function
void pthread_cleanup_pop(int execute);
The execute parameter gives you a chance to run the cleanup routine currently at the top of the cleanup stack. If you pass a value of 1, the routine will be executed. If you pass a value of zero, the routine will be removed from the stack but it will not be executed.
Handling Thread Termination in Carbon Mulitprocessing Services
To terminate a thread in application using Carbon Multiprocessing Services, you can:
- Return from the thread function
- Call the
MPExitfunction from within the thread function - Call the
MPTerminateTaskfunction from another thread
When a thread function exits, its return value is posted to the message notification queue that was passed to the MPCreateTask function. Similarly, the MPExit function, which has the signature:
void MPExit(OSStatus status);
will post the status parameter to the thread’s notification queue.
To synchronize one thread with the completion of another thread (similar to calling WaitForSingleObject on a thread handle in Win32), you call the MPWaitOnQueue function. The signature of MPWaitOnQueue is:
OSStatus MPWaitOnQueue(MPQueueID queue, void **param1, void **param2, void **param3);
Returning an exit code from a thread function works as follows. Recall that the MPCreateTask function takes two parameters of type void * ,called terminationParameter1, and terminationParameter2. These two parameters correspond to the param1 and param2 arguments of the MPWaitOnQueue function. Their programmer-defined values should reflect the fact that a thread has exited. The third argument of MPWaitOnQueue, param3, is the thread function’s return value, or the value passed to MPExit.
As with every multithreading package, asynchronously terminating a thread can cause serious problems and should be avoided if possible. Resources created in a thread are not released when the thread is terminated, and synchronization mechanisms such as critical regions are left in an indeterminate state.
That said, there are cases where thread termination is relatively safe. For example, if a thread is known to be waiting on a resource such as a queue or a semaphore, you could use MPTerminateTask. The correct way to use this function is to call it and when wait on the task’s notification queue until a message arrives. The signature of MPTerminateTask is:
OSStatus MPTerminateTask(MPTaskID task, OSStatus terminationStatus);
The terminationStatus argument is again returned as param3 in the call to MPWaitOnQueue. The thread calling MPTerminateTask and waiting on the queue should then handle cleanup of resources, since the terminated thread itself cannot.
Handling Thread Termination with Cocoa Threads
A thread created with the Cocoa NSThread class is detached, meaning its return status code is not retrievable in the same way as with Win32 or in the pthreads library.
The fact that a Cocoa thread is detached does not mean the thread cannot indicate a return status code, however. The status code could easily be a member variable of a class. You could pass the class as a parameter to the thread function.
A notification of type NSThreadWillExitNotification is sent to all registered observers before the thread function terminates. This allows observers to read the thread’s exit code. For more information on Notifications, see the topic Introduction to Notifications.
Thread Local Storage
The Win32 thread local storage (TLS) API maps fairly well to both pthreads and the Carbon Multiprocessing APIs. The Cocoa NSThread class maintains one instance of the NSMutableDictionary class (a table of key-value pairs) that you can use for storing thread-specific data.
In all three cases the concept is basically the same as on Win32: if you need to store a piece of interesting information about a thread, you request a unique key and then call functions to get or set the value
'[Develope] > Network' 카테고리의 다른 글
| [펌] [Solaris] ifconfig 사용법... (0) | 2005.08.26 |
|---|---|
| [펌] FreeBSD 핸드북 (0) | 2005.08.11 |
| per-process timer :: timer_create (0) | 2005.06.13 |
| per-process timers :: timer_getoverrun, timer_gettime, timer_settime (0) | 2005.06.13 |
| [펌] autoconf, automake (0) | 2005.06.02 |