A mutex lock design that effectively prevents deadlocks

The following is a passage from the internet. I think it is very good. It is helpful for understanding locks. "Why lock? The lock is used to prevent confusion caused by different threads accessing the same shared resource.
For example, a person is a different thread and a bathroom is a shared resource.
When you are in the bathroom, you must lock the door. This is the lock. As long as you are inside, the bathroom will be locked. Only when you come out Can someone else use it. Imagine what it would be like if there is no lock on the bathroom door?
What is lock granularity? The so-called locking granularity is the scope of the lock.
For example, if you are in the bathroom at home, you only need to lock the bathroom. You do not need to lock the whole House to prevent your family from entering the door. The bathroom is your locking granularity.
How can we calculate a reasonable lock granularity?
In fact, the bathroom is not just used to go to the toilet. You can also take a bath and wash your hands. This involves optimizing the locking granularity.
When you take a bath in the bathroom, you can also wash your hands in the bathroom at the same time. You only need to isolate them. If the restroom, bathtub, and washboard are separate, in fact, the bathroom can be used by three people at the same time. Of course, the three people cannot do the same thing. In this way, the locking granularity is refined. When you take a bath, you only need to close the bathroom door, and others can still go in and wash their hands. If different functional areas are not isolated when the toilet is designed, the maximum use of toilet resources cannot be achieved. This is the importance of the design architecture ." From the above, there is a situation where, when you enter the bathroom and lock the door, you escape from the window, causing the bathroom to be locked forever. This is one of the deadlocks.
So we can imagine that when we come out of the bathroom (whether it is normal, or fly out,...), we can open the lock and other people will be able to come in. The following code can implement this function.
Metux. h

# Ifndef mutex_lock_h # define mutex_lock_h # ifndef Win32 # include <windows. h> # endif # ifdef _ UNIX # include <pthread. h> # endif // _ unixclass mutex {public: mutex ();~ Mutex (); void lock (); void unlock (); Private: mutex (const mutex &); void operator = (const mutex &); # ifdef win32critical_section m_mutex; # endif // Win32 # ifdef _ unixpthread_mutex_t m_mutex; # endif // _ UNIX}; Class mutexlock {public: explicit mutexlock (mutex * mutex): m_mutex (mutex) {m_mutex-> lock ();};~ Mutexlock () {m_mutex-> unlock () ;}; PRIVATE: // copy mutexlock (const mutexlock &); void operator = (const mutexlock &); mutex * m_mutex;}; # endif //! Mutex_lock_h

Mutex. cpp

#include "mutex.h"Mutex::Mutex(){#ifdef WIN32InitializeCriticalSection(&m_mutex);#endif#ifdef __unixpthread_mutex_init(&m_mutex, NULL);#endif // __unix}Mutex::~Mutex(){#ifdef WIN32DeleteCriticalSection(&m_mutex);#endif#ifdef __unixpthread_mutex_destroy(&m_mutex);#endif // __unix}void Mutex::Lock(){#ifdef WIN32EnterCriticalSection(&m_mutex);#endif#ifdef __unixpthread_mutex_lock(&m_mutex);#endif // __unix}void Mutex::Unlock(){#ifdef WIN32LeaveCriticalSection(&m_mutex);#endif#ifdef __unixpthread_mutex_unlock(&m_mutex);#endif // __unix}

Test

Mutex mutex;void MutexTest(){MutexLock l(&mutex);static int  i = 0;printf("i = %d\n", i);++i;}

The principle is that at the end of the mutexlock lifecycle, The Destructor will be called to unlock the mutexlock every time it comes out of the bathroom. Of course, you can add braces ({}) in mutextext to constrain the lifecycle of metexlock, so as to reduce the lock granularity.
This design is simple, either in principle or in practice. The premise is that you have experience in this area before you can think of this implementation method.
Link: http://www.guimigame.com/thread-685-1-1.html