Shulou(Shulou.com)06/02 Report--

Editor to share with you a variety of lock mechanisms in linux and the differences between the use of details, I believe that most people do not understand, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to understand it!

Foreword:

It is believed that the partners who need to know about this already have a basic understanding of inter-process communication and inter-thread communication. For example, one of the mechanisms of inter-process communication: shared memory (not detailed here): multiple processes can access the same block of memory at the same time. If the critical areas that access this piece of memory are not mutually exclusive or synchronized, then the running of the process is likely to have some unpredictable errors and results.

Let's take a look at three common mutexes under Linux-> locks.

1. Mutex (mutex)

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

Create a lock:

There are two ways to create mutexes, static and dynamic. POSIX defines a macro PTHREAD _ MUTEX_INITIALIZER to statically initialize the mutex

The methods are as follows:

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 way is to use the pthread_mutex_init () function to initialize the mutex. API is defined as follows:

Int pthread_mutex_init (pthread_mutex_t * mutex, const pthread_mutexattr_t*mutexattr)

Where mutexattr is used to specify the mutex attribute (see below), and if it is NULL, the default attribute is used. Pthread_mutex_destroy () is used to log out a mutex, and API is defined as follows:

Int pthread_mutex_destroy (pthread_mutex_t * mutex)

Locking 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 get it at the same time, but must wait for it to be unlocked. For ordinary locks and adaptive lock types, the unlock can be any thread in the same process; the error detection lock must be unlocked by the lock holder to be effective, otherwise return EPERM; for nested locks, the document and implementation requirements must be unlocked by the lock holder, but the experimental results show that there is no such restriction, and this difference has not been explained yet. If a thread in the same process is not unlocked after being locked, no other thread can acquire 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 pthread_mutex_lock (), except that it returns EBUSY when the lock is occupied instead of suspending waiting.

For example: thread-safe locking in singleton mode:

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

Advantages:

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 CPU in assembly language, and a process can wait until that value becomes positive. Almost all of the operations are done in the application space; only when the results of the operations are inconsistent and thus require arbitration, do you need to enter the operating system kernel space for execution. The locking primitives allowed by this mechanism are very efficient: since the vast majority of operations do not need to be arbitrated between multiple processes, most operations can be performed in application space without the use of (relatively expensive) kernel system calls

Use it.

two。 Read-write lock

Features: read-write locks are suitable for situations where the data structure is read more times than written. Read-write locks are also called shared-exclusive locks because they can be shared when locked in read mode and exclusive when locked in write mode.

Initialize and destroy:

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 for success and error number for error. With the same mutex or more, before releasing the memory occupied by the read-write lock, it is necessary 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)

Returns 0 for success and error number for error. These three functions realize the operation of acquiring read lock, acquiring write lock and releasing lock respectively. The two functions that acquire the lock are blocking operations, and similarly, the non-blocking functions are:

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

Returns 0 for success and error number for error. Non-blocking acquisition lock operation, returns 0 if it can be obtained, otherwise returns the wrong EBUSY.

3. Spin lock

Features: polling busy waiting.

Does not work under single-core cpu: the critical section code protected by the spin lock cannot be suspended during execution. Can cause a deadlock.

The original purpose of spin lock is to perform lightweight locking in a short period of time. A contended spin lock causes the requesting thread to spin while waiting for the lock to be available again (especially a waste of processor time), so the spin lock should not be held for too long. If it takes a long time to lock, it is best to use semaphores.

API:

The above is all the contents of this article entitled "detailed explanation of the use and differences of various locking mechanisms in linux". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.