1. What is a mutex
Computer, when multiple processes or threads share a critical section (for example: a shared memory space or global variables), if only reads the critical region, not modify the content, even while multiple reads are no problem.
However, when we need to modify the contents of the critical region, we must face a situation: there are multiple actions on the content of the critical region to be modified, after the operation, the result of that is reserved for one operation? To address this
Problem, you can modify the operation of the provisions of the critical areas, while only a maximum of one to modify. One way the program is implemented mutex.
Mutex, it has three characteristics:
(I) atomicity: a mutex lock the righteous is an atomic operation, which means that the operating system ensures that if a thread locks the mutex, no other thread can successfully lock the mutex at the same time.
(Ii) Uniqueness: If a thread locks a mutex, before it contacts the lock, no other thread can lock the mutex.
(III) a non-busy waits:如果一个线程已经锁定了一个互斥锁，第二个线程又试图去锁定这个互斥锁，则第二个线程将被挂起（不占用CPU资源），直到第一个线程解锁，
第二个线程则被唤醒并继续执行，同时锁定这个互斥量。
Simple to understand, is that a lot of people need to compete only lock, grab people get a license to operate on the critical area, others can only wait. After the operation, after the lock is released, we continue to compete.
II. Mutex API
#inlcude <pthread.h> pthread_mutex_t the mutex; // defined mutex
1. Create
int pthread_mutex_init (pthread_mutex_t * mutex, const pthread_mutexattr_t * attr); // return 0 if successful, otherwise returns an error code pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
2. Obtain
// lock contention, less than a blocking competition, after waiting for the lock is released, the competition again int pthread_mutex_lock (pthread_mutex_t * mutex); // try to lock competition, competitive success returns 0 if the lock has been acquired by another thread, returning an error code EBUSY ; // whether or not to compete successfully, will return immediately and will not block waiting int pthread_mutex_trylock (pthread_mutex_t * mutex); // lock limit competition, time is absolute time, // you want to set a time limit, first with the function to get the current clock_gettime time, plus the time to set the time, as the value of the parameter abs_timeout int pthread_mutex_timedlock (pthread_mutex_t * mutex, const struct timespec * abs_timeout);
3. Release
int pthread_mutex_unlock (pthread_mutex_t * mutex); // release the mutex, the successful return 0, else return an error code
4. Destruction
int pthread_mutex_destroy (pthread_mutex_t * mutex); // returns 0 on success, failure to return an error code number
note:
1, mutex needs time to lock and unlock. Mutex lock small programs usually run faster. So, mutex should be used sparingly, can be enough, each area should be protected by the mutex is as large as possible.
2, the mutex is essentially a serial execution. If you need to lock many threads with a mutex frequently, most of the time the thread will be waiting, this performance is harmful. If the mutex protected data (or code) comprising
Of unrelated fragments, it can be decomposed into a large mutex mutex several small to improve performance. In this way, any time require a small reduction mutex thread, the thread waiting time will be reduced. So, mutex should be enough
(To the point of interest), each mutex protected area should try less.
3, Linux implementation of POSIX thread-locking mechanism is not a cancellation point, therefore, delay cancel the type of thread will not receive a cancellation signal while waiting to leave the lock.
4, the thread is canceled before unlocking the lock, the lock will remain locked forever. So if there is a cancellation point in the critical section, set or cancel the asynchronous type, you must unlock the exit callback function.
5, the lock mechanism is not safe asynchronous signal, that should not be used in mutex lock signal processing, or likely to cause a deadlock.