Atomic Operation interlocked Series functions (RPM)

On a " multi-threaded first intimate contact CreateThread and _beginthreadex essential Difference " mentioned in a multi-threaded count function. To describe the convenience and the code brevity, we can only output the last count of the results to see if the program is running in error. It's also very similar to how many users log in on a website per day, each user logging in with a thread emulation, and the thread running will increment a variable that represents a count. The value of the last output count of the program indicates how many users are logged in today, and if this value is not equal to the number of threads we started, it clearly indicates that the program is problematic. The entire program code is as follows:

2. #include <stdio.h>
4. #include <process.h>
6. #include <windows.h>
8. Volatile long G_nlogincount; //Login times
10. unsigned int __stdcall fun (void *ppm); //thread function
12. const int thread_num = 10; //number of startup threads
14. unsigned int __stdcall threadfun (void *ppm)
16. {
18. Sleep (100); //some work should
20. g_nlogincount++;
22. Sleep (50);
24. return 0;
26. }
28. int main ()
30. {
32. G_nlogincount = 0;
36. HANDLE Handle[thread_num];
38. For (int i = 0; i < thread_num; i++)
40. Handle[i] = (handle) _beginthreadex (null, 0, threadfun, NULL, 0, NULL);
44. WaitForMultipleObjects (Thread_num, handle, TRUE, INFINITE);
46. printf ("%d users log results after logging%d\n", Thread_num, G_nlogincount);
48. return 0;
50. }

The program simulates the user Login, the program will output the results:

As with the previous thread-count program, the output of the program seems to have no problem. Below we add a few users to try, now simulate 50 users login, in order to facilitate the observation of the results, in the program will be 50 user logon process repeated 20 times , the code is as follows:

2. #include <stdio.h>
4. #include <windows.h>
6. Volatile long G_nlogincount; //Login times
8. unsigned int __stdcall fun (void *ppm); //thread function
10. Const DWORD thread_num =; Number of startup threads
12. DWORD WINAPI threadfun (void *ppm)
14. {
16. Sleep (100); //some work should
18. g_nlogincount++;
20. Sleep (50);
22. return 0;
24. }
26. int main ()
28. {
30. printf ("Use of atomic operations interlocked series functions \ n");
32. printf ("-by Morewindows (http://blog.csdn.net/MoreWindows)--\n\n");
36. ///Repeat 20 times to observe the conflicts caused by multi-threaded access to the same resource
38. int num= 20;
40. While (num--)
42. {
44. G_nlogincount = 0;
46. int i;
48. HANDLE Handle[thread_num];
50. For (i = 0; i < thread_num; i++)
52. Handle[i] = CreateThread (null, 0, threadfun, NULL, 0, NULL);
54. WaitForMultipleObjects (Thread_num, handle, TRUE, INFINITE);
56. printf ("%d users log results after logging%d\n", Thread_num, G_nlogincount);
58. }
60. return 0;
62. }

Running results such as:

Now the results come to the bottom, clearly there are 50 threads executed g_nlogincount+ +; operation, but the output of the result is indeterminate, it may be, but it may be less than.

To solve this problem, we will analyzeG_nlogincount++; operation. In the VC6.0 compiler to G_nlogincount+ +; This statement hit a breakpoint, then press F5 to Enter the debug state, and then press the Debug toolbar disassembly button, so that the assembly Code window appears. It can be found that a simple self-increment statement in the C + + language is actually made up of three assembly code, as shown in.

Explain the following three articles of assembly meaning:

The first assembly reads the value of G_nlogincount from memory into the register eax.

The second assembly adds the value in the register eax to 1, and the result is still stored in the register eax.

The third assembly writes the values in the register EAX back into memory.

        So because of the concurrency of thread execution, it is likely that the thread a executes to the second sentence, thread b begins execution, thread b writes the original value to register a the main computed value is thread 50, possibly less than 50.

Therefore, when reading and writing a variable in a multithreaded environment, we need a way to ensure that an incremental operation on a value is atomic--that is, non-disruptive, that when a thread performs an atomic operation, the other thread must wait for it to complete before it can begin executing the atomic operation. This hardware-related operation will be complicated, fortunately, theWindows system provides us with some functions beginning with interlocked to accomplish this task (these functions are called Interlocked series functions below).

Some common interlocked series functions are listed below:

1. Increase or decrease operation

Long__cdeclinterlockedincrement(long volatile* Addend);

Long__cdeclinterlockeddecrement(long volatile* Addend);

Returns the value of the variable after the increment or decrement operation is performed .

Long__cdec interlockedexchangeadd(long volatile* Addend, longValue) ;

Returns the value after the operation, note! Adding a negative number is minus.

2. Assignment operation

Long__cdeclinterlockedexchange(long volatile* Target, longValue);

Value is the new value, and the function returns the original value.

In this case, you can just use the interlockedincrement() function. Change the thread function code to:

1. DWORD WINAPI threadfun (void *ppm)
2. {
3. Sleep (100); //some work should
4. //g_nlogincount++;
5. InterlockedIncrement ((lplong) &g_nlogincount);
6. Sleep (50);
7. return 0;
8. }

Run again, and you can see that the results will be unique.

Therefore, in the multi-threaded environment, we have to think carefully about these simple statements of variable self-increment, to prevent the data access error caused by multiple threads. For more information, please visit the Synchronization Functions section on MSDN at the address http://msdn.microsoft.com/zh-cn/library/aa909196.aspx

See here, I believe this series first "second multi-threaded the first multi-threaded written test questions summary" in the selection of the first question (Baidu written questions) should be able to kill the second (know it is also know why), the correct answer is D. In addition to an additional question, the program is to use 50 threads to impersonate the user login, interested students can try to use 100 threads to simulate (on the machine to try absolutely will have accidentally found ^_^).

The next "Seconds kill multithreading fourth a classic multi-threaded synchronization problem" will be a little more complicated but very classic multi-threaded synchronization mutex problem, this problem will be used in different ways to answer, so that you fully skilled multi-threaded synchronization mutually exclusive " moves." More exciting, please continue to see.

Reprint please indicate source, original address: http://blog.csdn.net/morewindows/article/details/7429155

If you feel that this article is helpful, please click on the ' top ' support, your support is my greatest motivation to write, thank you.

Atomic Operation interlocked Series functions (RPM)