POSIX Thread Programming Guide (3)

Mutex lock

Although the IPC semaphore mechanism can also be used in POSIX thread to implement mutex functions, the semphore function is obviously too powerful, the POSIX thread defines another set of mutex functions for thread synchronization.

1. create and destroy

There are two ways to create mutex lock, static mode and dynamic mode. POSIX defines a macro pthread_mutex_initializer to statically initialize mutex locks. The method is as follows: pthread_mutex_t mutex = timeout; In linuxthreads implementation, pthread_mutex_t is a structure, while pthread_mutex_initializer is a structure.

The dynamic mode uses the pthread_mutex_init () function to initialize the mutex lock. The API definition is as follows: int pthread_mutex_init (pthread_mutex_t * mutex, const pthread_mutexattr_t * mutexattr) here, mutexattr is used to specify the mutex lock attribute (see below). If it is null, the default attribute is used.

Pthread_mutex_destroy () is used to cancel a mutex lock. The API definition is as follows: int pthread_mutex_destroy (pthread_mutex_t * mutex) to destroy a mutex lock, which means to release the resources it occupies, the lock is currently open. In Linux, mutex locks do not occupy any resources. Therefore, pthread_mutex_destroy () in linuxthreads has no action except checking the lock status (ebusy is returned when the lock status is locked.

2. mutex lock attributes

The mutex lock attribute is specified when the lock is created. There is only one lock type attribute in the linuxthreads implementation. Different lock types are different when trying to lock a locked mutex lock. Currently (glibc2.2.3, linuxthreads0.9) has four values available:

• Pthread_mutex_timed_np, which is the default value, that is, the common lock. When a thread locks, other threads requesting the lock form a waiting queue and obtain the lock by priority after unlocking. This lock policy ensures the fairness of resource allocation.
• Pthread_mutex_recursive_np: Nested lock, which allows the same thread to successfully obtain the same lock multiple times and unlock the lock multiple times. For different thread requests, re-compete when the lock thread is unlocked.
• Pthread_mutex_errorcheck_np: Check the error lock. If the same thread requests the same lock, edeadlk is returned. Otherwise, the action is the same as that of the pthread_mutex_timed_np type. This ensures that no deadlock will occur in the simplest case when many locks are not allowed.
• Pthread_mutex_adaptive_np: the most simple lock type to adapt to the lock. It only waits for the unlock before re-competition.

3. Lock Operation

The lock operation mainly includes locking pthread_mutex_lock (), unlocking pthread_mutex_unlock (), and testing locking pthread_mutex_trylock (). No matter which type of lock, it cannot be obtained by two different threads at the same time, you must wait for unlocking. For common locks and adaptive lock types,The unlock can be any thread in the same process.;The error lock must be unlocked by the locker.Otherwise, the EPERM is returned. For nested locks, the document and implementation requirements must be unlocked by the locker. However, the experiment results show that there is no such restriction. This difference is not yet explained. If the lock is not unlocked for a thread in the same process, no other thread can obtain the lock again.

int pthread_mutex_lock(pthread_mutex_t *mutex)int pthread_mutex_unlock(pthread_mutex_t *mutex)int pthread_mutex_trylock(pthread_mutex_t *mutex)

The semantics of pthread_mutex_trylock () is similar to that of pthread_mutex_lock (). The difference is that EBUSY is returned when the lock is occupied rather than waiting.

4. Miscellaneous

The implementation of POSIX thread lock mechanism in Linux is not a cancellation point. Therefore, threads with delayed cancellation do not leave the lock wait because they receive the cancellation signal. It is worth noting that if the thread is canceled before being unlocked after the lock is applied, the lock will always remain locked. Therefore, if there is a cancellation point in the key segment, or, if the asynchronous cancellation type is set, you must unlock it in the exit callback function.

This lock mechanism is not asynchronous signal security at the same time. That is to say, mutex locks should not be used during signal processing; otherwise, deadlock may occur..

Condition variable

Conditional variables are a mechanism for synchronizing global variables shared between threads. They mainly include two actions:One thread waits for "condition variable condition is true", and the other thread suspends "condition is true" (a signal indicating condition is true ). To prevent competition, condition variables are always used together with a mutex lock..

1. Create and log out

Like mutex lock, conditional variables have two static and dynamic creation methods. The static method uses the PTHREAD_COND_INITIALIZER constant, as shown below:
Pthread_cond_t cond = PTHREAD_COND_INITIALIZER

Call the pthread_cond_init () function dynamically. The API is defined as follows:
Int pthread_cond_init (pthread_cond_t * cond, pthread_condattr_t * cond_attr)

Although the POSIX standard defines attributes for condition variables, they are not implemented in LinuxThreads. Therefore, the cond_attr value is usually NULL and ignored.

To cancel a condition variable, you must call pthread_cond_destroy (),This condition variable can be deregistered only when no thread waits on this condition variable; otherwise, EBUSY is returned. Because the condition variables implemented in Linux do not allocate any resources, the logout action only includes checking whether there are waiting threads. The API is defined as follows:
Int pthread_cond_destroy (pthread_cond_t * cond)

2. Waiting and stimulating

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)

There are two ways to wait for a condition:Unconditionally wait for pthread_cond_wait () and timing wait for pthread_cond_timedwait (),If the time Wait method is not met before the given time, ETIMEOUT is returned,Abstime appears in the absolute time format of the same meaning as the time () system call. 0 indicates January 1, January 1, 1970 00:00:00 GMT..

Either way, you must work with a mutex lock to prevent multiple threads from simultaneously requesting the Race Condition of pthread_cond_wait () (or pthread_cond_timedwait (), the same below ). Mutex locks must be common locks (PTHREAD_MUTEX_TIMED_NP) or adaptive locks (PTHREAD_MUTEX_ADAPTIVE_NP), and must be locked by this thread before pthread_cond_wait () is called ()), before the update condition is waiting for the queue, mutex remains locked and is unlocked before the thread is suspended and enters the waiting state. Before the condition is met and pthread_cond_wait () is left, mutex is re-locked to match the lock action before pthread_cond_wait.

There are two types of conditions to be triggered. pthread_cond_signal () activates a thread waiting for this condition. When multiple threads are waiting, one of them is activated in the queue order. pthread_cond_broadcast () activates all waiting threads..

3. Miscellaneous

Pthread_cond_wait () and pthread_cond_timedwait () are both implemented as cancellation points. Therefore, the thread waiting for this point will immediately run again and leave pthread_cond_wait () after re-locking mutex (), then, cancel the operation. That is to say, if pthread_cond_wait () is canceled, mutex remains locked. Therefore, you need to define the exit callback function to unlock it.

The following example demonstrates the combination of mutex lock and condition variable, and the impact of cancellation on the conditional wait action. In this example, two threads are started and wait for the same condition variable. If you do not use the exit callback function (see the comments section in this example), tid2 will be in pthread_mutex_lock () wait permanently. If the callback function is used, the condition wait of tid2 and the condition excitation of the main thread can work normally.

# Include <stdio. h>
# Include <pthread. h>
# Include <unistd. h>
Pthread_mutex_t mutex;
Pthread_cond_t cond;
Void * child1 (void * arg)
{
Pthread_cleanup_push (pthread_mutex_unlock, & mutex);/* comment 1 */
While (1 ){
Printf ("thread 1 get running \ n ");
Printf ("thread 1 pthread_mutex_lock returns % d \ n ",
Pthread_mutex_lock (& mutex ));
Pthread_cond_wait (& cond, & mutex );
Printf ("thread 1 condition applied \ n ");
Pthread_mutex_unlock (& mutex );
Sleep (5 );
}
Pthread_cleanup_pop (0);/* comment 2 */
}
Void * child2 (void * arg)
{
While (1 ){
Sleep (3);/* comment 3 */
Printf ("thread 2 get running. \ n ");
Printf ("thread 2 pthread_mutex_lock returns % d \ n ",
Pthread_mutex_lock (& mutex ));
Pthread_cond_wait (& cond, & mutex );
Printf ("thread 2 condition applied \ n ");
Pthread_mutex_unlock (& mutex );
Sleep (1 );
}
}
Int main (void)
{
Int tid1, tid2;
Printf ("hello, condition variable test \ n ");
Pthread_mutex_init (& mutex, NULL );
Pthread_cond_init (& cond, NULL );
Pthread_create (& tid1, NULL, child1, NULL );
Pthread_create (& tid2, NULL, child2, NULL );
Do {
Sleep (2);/* comment 4 */
Pthread_cancel (tid1);/* comment 5 */
Sleep (2);/* comment 6 */
Pthread_cond_signal (& cond );
} While (1 );
Sleep (100 );
Pthread_exit (0 );
}

 

If you do not comment 5 on the pthread_cancel () Action, child1 and child2 work normally even if there are no sleep () Delayed operations. Note 3 and note 4 delay makes child1 have time to complete the cancellation action, so that child2 can enter the request Lock operation after child1 exits. If the callback function definition of comment 1 and comment 2 is not defined, the system will suspend the child2 request lock. If the latency of comment 3 and comment 4 is not included at the same time, child2 can be controlled before child1 completes the cancellation action, so that the lock application operation can be smoothly executed, but it may be suspended in pthread_cond_wait (), because there are also mutex application operations. The child1 function provides the usage of standard condition variables: callback function protection, locking before the condition, and unlocking after pthread_cond_wait () is returned.

The Conditional Variable mechanism is not asynchronous signal security, that is, calling pthread_cond_signal () or pthread_cond_broadcast () in the signal processing function may cause a deadlock.

Signal lamp

The main difference between traffic lights and mutex locks and condition variables lies in the concept of "Lights". When lights are on, resources are available, and when lights are off, they are unavailable. If the synchronization mode in the last two phases focuses on "Waiting" operations, that is, the resource is unavailable, the traffic signal mechanism focuses on lighting, that is, to inform the resource availability; it makes no sense to unlock a thread without waiting for it or to stimulate the conditions. The lighting operation of a thread without waiting for it is effective and can be kept on. Of course, such operation primitives also mean more overhead.

In addition to the binary lamp, the application of traffic signals can also use a lamp number greater than 1 to indicate that the number of resources is greater than 1.

1. Create and log out

POSIX signal lights are defined as well-known signal lights and unknown signal lights, but the implementation of LinuxThreads only has unknown lights. Besides being well-known lights, they can always be used between multiple processes, there is no major difference between the use of lamps and lamps, so we will only discuss lamps.

Int sem_init (sem_t * sem, int pshared, unsigned int value)
This is the API for creating traffic signals. value indicates the initial value of the traffic signal. pshared indicates whether to share the traffic signal with multiple processes rather than just one process. Linuxthreads does not implement multi-process shared traffic signals. Therefore, all non-0 pshared inputs will return-1 for sem_init () and set errno to enosys. The initialized signal lights are characterized by SEM variables and used for the following lighting and lamp removal operations.

Int sem_destroy (sem_t * SEM)
The canceled signal SEM requires that no thread is waiting for the signal. Otherwise,-1 is returned and errno is set to ebusy. In addition, threads's signal cancellation function does not perform any other action.

2. Lighting and lighting Removal

int sem_post(sem_t * sem)

The light-on operation adds 1 to the value of the signal lamp, indicating that an accessible resource is added.

int sem_wait(sem_t * sem)int sem_trywait(sem_t * sem)

Sem_wait () is to wait for the light to shine, wait for the light to shine (the signal light value is greater than 0), then reduce the signal light by 1 and return. Sem_trywait () is a non-blocking version of sem_wait (). If the traffic signal count is greater than 0, 1 is reduced and 0 is returned. Otherwise,-1 is returned immediately, and errno is set to eagain.

3. Get the lamp Value

int sem_getvalue(sem_t * sem, int * sval)

Read the lamp count in SEM, save it in * sval, and return 0.

4. Miscellaneous

Sem_wait () is implemented as a cancellation point, and in the architecture that supports atomic "comparison and exchange" commands, sem_post () it is the only POSIX asynchronous signal security API that can be used for asynchronous signal processing functions.

Asynchronous Signal

Because linuxthreads is implemented by a lightweight process outside the kernel, kernel-based Asynchronous signal operations are also effective for threads. But at the same time, because the asynchronous signal is always actually sent to a process, it is impossible to implement the POSIX standard requirement to "signal to a process, then, the process distributes the signal to all threads that do not block the signal. "The primitive affects only one thread.

POSIX asynchronous signal is also a function provided by the Standard C library, mainly including Signal Set Management (sigemptyset (), sigfillset (), sigaddset (), sigdelset (), sigismember (), etc), signal processing function installation (sigaction (), signal blocking control (sigprocmask (), blocked signal query (sigpending (), signal waiting (sigsuspend (), etc, they work with functions such as kill () for sending signals to Implement Asynchronous signal functions between processes. Linuxthreads encapsulates sigaction () He raise () around the thread. This section focuses on the extended asynchronous Signal Functions in linuxthreads, including pthread_sigmask (), pthread_kill (), and sigwait () three functions. Undoubtedly, all POSIX asynchronous signal functions are available to threads.

Int pthread_sigmask (INT how, const sigset_t * newmask, sigset_t * oldmask)
Sets the thread's signal shielding code. The semantics is the same as sigprocmask (), but the cancel signals that are not blocked and the restart signals that are not allowed to respond are protected. Blocked signals are stored in the signal queue and can be taken out by the sigpending () function.

Int pthread_kill (pthread_t thread, int signo)
Sends a signo signal to the thread. After the corresponding process number is located through the thread number, the kill () system call is used to complete sending.

Int sigwait (const sigset_t * Set, int * sig)
Suspends a thread, waits for one of the signals specified in the set to arrive, and stores the signals to * Sig. POSIX standard recommends that all threads in the Process Shield the signal before calling the sigwait () Wait signal to ensure that only the sigwait () caller obtains the signal, for asynchronous signals waiting for synchronization, pthread_sigmask () should always be called to shield the signal before any threads are created. In addition, the signal processing function attached to the signal will not be called when sigwait () is called.

If the cancel signal is received during the waiting period, exit the waiting immediately, that is, the sigwait () is implemented as the canceling point.

Other Synchronization Methods

In addition to the synchronization methods discussed above, many other inter-process communication methods are also available for linuxthreads, such as file system-based IPC (pipelines, Unix domain sockets, etc.) and Message Queue (sys. V or POSIX) and System V signal lights. Note that linuxthreads is viewed in the kernel as an independent process of shared storage area, shared file system attributes, shared signal processing, and shared file descriptor.