In the previous article I introduced a way to use mutexes conveniently by enclosing the critical section object, all of which are two threads read and write to the same data, so they need to be mutually exclusive and not accessible at the same time. In reality, there may be more complex situations where multiple threads access the same data, partly read, and partly write. We know that there may be problems with both read-write or write-write, while read-read can be done at the same time, because they do not modify the data, it is also necessary in C + + to encapsulate a convenient read-read concurrency, read-write and write-write mutual exclusion of the lock. To implement this lock, it is difficult to use a critical section, instead of a kernel object, where I use a mutex (mutex).
The overall structure, similar to the one in the previous article, is to write a base class that encapsulates the lock, and then write a class that invokes the add-and-unlock function, by locking and unlocking the lifecycle management of the second class. Here are two new problems, one is lock, unlock action have two kinds, one is the addition/interpretation of locks, one is the Add/write lock, and the other is to allow read-read concurrency, it is not enough to declare only one mutex, you must declare multiple mutexes, and how many of the mutex will allow the number of read threads concurrent, The reason for this is that the API function we want to use is waitformultipleobjects.
The function of the WaitForMultipleObjects function is to wait for the object state to be set, as explained in MSDN:
Waits until one or all of the specified objects are in the signaled state or the time-out interval.
This is a very useful function that we can use to wait for one or several objects, and to allow the timeout to be set, and to wait for success to be different from the value returned at timeout. If the value returned is smaller than the wait_abandoned, the wait is successful. "Wait for success" has different meanings for different types of kernel objects, for example, for a process or thread object, waiting for success indicates that a process or thread execution has ended; For a mutex object, the object is now not owned by any other thread, and once the wait succeeds, the current thread has the mutex. Other threads cannot have both, directly calling the ReleaseMutex function to voluntarily release the mutex.