Atomic lock of multi-threaded programming

In the article "Data access mutual exclusion of multi-threaded programming", the Atom Lock is briefly introduced, and the concept and use of atomic lock are described in detail here.

(1) Simple data operation

If you perform a simple mathematical operation or a logical operation on a variable in a multithreaded environment, you should use atomic lock operations. Because the use of the critical section, mutex, and other thread mutex will involve a lot of operating system calls and function calls, etc., efficiency certainly not as high as atomic operation. For example, there is an example:

int 0 ; int data_process () {    if(/**/) {         entercriticalsection ( &CS);          + + count;         LeaveCriticalSection (&CS);             }}

There are only simple mathematical operations, which can be replaced by the atomic operation provided by the operating system, which is much more efficient:

int 0 ; int data_process () {    if(/**/) {        interlockedincrement ( &count);}           }

(2) Mutex in the code snippet

In the case of a critical section, for example, the following critical section is applied to the code snippet:

void data_process () {    entercriticalsection (&CS);    do_something ();    LeaveCriticalSection (&CS);   }

In fact, the atomic lock can be used instead of the critical section, the implementation is as follows:

int Lock 0 ; void data_process () {    while (1 = = InterlockedCompareExchange (&lock1  0));    do_something ();      Lock 0 ;    }

The meaning of the InterlockedCompareExchange method is to compare the value of the first parameter to the value of the third parameter, if it is equal, to exchange the value of the second parameter, and not to operate if not equal; The return value is the initial value of the first parameter, The operation of this function is atomic and is not interrupted by multithreading and can be applied to all CPUs.

The code above means that the lock value is constantly monitored, and when the lock value is 0 o'clock, InterlockedCompareExchange turns it to 1, executes do_something (), and finally restores the lock to 0. Of course, if lock is 1 at this point, the while loop will continue to execute ("Busy").

In fact, in this case, we will find that there is a problem here: if another thread will lock to 1 and it will take a long time , then this is not crazy? That's right, so this method of atomic locking is applicable to the mutex of the short-time operation thread, and it is not an alternative to all the system mutex invocation situations. The critical section will be more advantageous at this point.

Atomic lock of multi-threaded programming