Detailed explanation of the use and differences of various lock mechanisms in Linux

Preface:

I believe that those who need to understand this knowledge already have a basic understanding of inter-process communication and inter-thread communication. For example, one of the mechanisms of inter-process communication is shared memory (not explained in detail here): multiple processes can access the same block of memory at the same time. If the critical section accessing this memory is not mutually exclusive or synchronized, the running of the process is likely to have some unpredictable errors and results.

Next, we will learn about three common mutual exclusion operations under Linux—> locks.

1. Mutex

Features: For readers and writers. As long as one party acquires the lock, the other party cannot continue to acquire it and execute the critical section code.

Create a lock:

There are two ways to create a mutex, statically and dynamically. POSIX defines a macro PTHREAD_MUTEX_INITIALIZER to statically initialize the mutex.

Here’s how:

pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER;

In the LinuxThreads implementation, pthread_mutex_t is a structure, and PTHREAD_MUTEX_INITIALIZER is a structure constant.

The dynamic method 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)

mutexattr is used to specify the mutex attributes (see below). If it is NULL, the default attributes are used. pthread_mutex_destroy() is used to cancel a mutex. The API definition is as follows:

int pthread_mutex_destroy(pthread_mutex_t *mutex)

The lock operations mainly include locking pthread_mutex_lock(), unlocking pthread_mutex_unlock() and testing locking pthread_mutex_trylock(). No matter which type of lock, it is impossible for two different threads to obtain it at the same time, and they must wait to be unlocked. For ordinary locks and adaptive lock types, the unlocker can be any thread in the same process; while the error detection lock must be unlocked by the lock holder to be effective, otherwise EPERM is returned; for nested locks, the documentation and implementation require that the lock holder must unlock the lock, but experimental results show that there is no such restriction. This difference has not yet been explained. If a thread in the same process locks a block but does not unlock it, no other thread can obtain the lock.

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() are similar to those of pthread_mutex_lock(), except that it returns EBUSY instead of hanging waiting when the lock is already occupied.
For example: In singleton mode, thread-safe locking:

class SingleTon 
{ 
public: 
static SingleTon* getInstance() 
{ 
pthread_mutex_lock(&mutex); 
if(mpSingle == NULL) 
{ 
mpSingleTon = new SingleTon(); 
} 
pthread_mutex_unlock(&mutex); 
return mpSingleTon; 
} 
private: 
SingleTon(){}; 
~SingleTon(){pthread_mutex_desttroy(&mutex,NULL);} 
static pthread_mutex_t mutex; 
static SingleTon *mpSingleTon; 
} 
pthread_mutex_t SingleTon::mutex = PTHREAD_MUTEX_INITIALIZER; 
SingleTon * SingleTon::mpSingleTon = NULL;

advantage:

It consists of a piece of memory space (an aligned integer variable) that can be shared by multiple processes; the value of this integer variable can be increased or decreased by calling the atomic operation instructions provided by the CPU in assembly language, and a process can wait until that value becomes a positive number. Almost all operations are completed in the application space; only when the operation results are inconsistent and arbitration is required, it is necessary to enter the operating system kernel space for execution. This mechanism allows the use of locking primitives with very high execution efficiency: since most operations do not require arbitration between multiple processes, most operations can be performed in application space without using (relatively expensive) kernel system calls.

2. Read-write lock

Features: Read-write locks are suitable for situations where the number of reads of a data structure is much greater than the number of writes. Because it can be shared when locked in read mode, and locked in write mode means exclusive, so the read-write lock is also called a shared-exclusive lock.

Initialization and destruction:

int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock, const 
pthread_rwlockattr_t *restrict attr); 
int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);

Returns 0 if successful, and an error number if an error occurs. As with the mutex, before releasing the memory occupied by the read-write lock, you need to clean up the read-write lock through pthread_rwlock_destroy to release the resources allocated by init.

Read and Write:

int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock); 
int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock); 
int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);

If successful, it returns 0, and if an error occurs, it returns an error number. These three functions implement the operations of acquiring a read lock, acquiring a write lock, and releasing a lock respectively. The two functions for acquiring a lock are blocking operations. Similarly, the non-blocking functions are:

int pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock); 
int pthread_rwlock_trywrlock(pthread_rwlock_t *rwlock);

If successful, it returns 0, and if an error occurs, it returns an error number. For non-blocking lock acquisition operations, it returns 0 if the lock can be acquired, otherwise it returns the error EBUSY.

3. Spin lock

Features: Polling busy waiting.

It does not work on a single-core CPU: the critical section code protected by the spin lock cannot be suspended during execution. The original intention of the spin lock that causes deadlock is to perform lightweight locking in a short period of time. A contended spin lock causes the thread requesting it to spin while waiting for the lock to become available again (which is a waste of processor time), so spin locks should not be held for too long. If you need to lock for a long time, it is better to use a semaphore.

API:

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. If you have any questions, you can leave a message to communicate. Thank you for your support for 123WORDPRESS.COM.