Pthread_mutex_init & Use of mutex lock pthread_mutex_t)

1. Create a mutex lock

There are two ways to create mutex lock, static mode and dynamic mode. POSIX defines a macro pthread_mutex_initializer to statically initialize the mutex lock. The method is as follows:
Pthread_mutex_t mutex = pthread_mutex_initializer;
In linuxthreads implementation, pthread_mutex_t is a structure, while pthread_mutex_initializer is a structural constant.
The dynamic mode is to use 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 is defined as follows:
Int pthread_mutex_destroy (pthread_mutex_t * mutex)

Destroying a mutex lock means releasing the resources it occupies and requires the lock to be 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 it through multiple unlocks. 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 unlocking and then re-competing.

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 locks, the locker can be any thread in the same process, and the error locks 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, but 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.