{"id":4846,"date":"2016-08-03T07:11:18","date_gmt":"2016-08-03T07:11:18","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/ongoing-optimization-2\/"},"modified":"2023-06-26T12:47:37","modified_gmt":"2023-06-26T12:47:37","slug":"ongoing-optimization-2","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/ongoing-optimization-2\/","title":{"rendered":"Ongoing Optimization: Unsynchronized Access with CppMem"},"content":{"rendered":"

I described my challenge in the last post. Let’s ‘s start with our process of ongoing optimization<\/a>. To be sure, I verify my reasoning with CppMem.<\/a> I once made a big mistake in my presentation at Meeting C++ 2014<\/a>.<\/p>\n

<\/p>\n

 <\/p>\n

To remind you. That is our starting point.<\/p>\n

<\/span>The program<\/span><\/h2>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24<\/pre>\n<\/td>\n
\n
\/\/ ongoingOptimization.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n\r\nint<\/span> x= 0;\r\nint<\/span> y= 0;\r\n\r\nvoid<\/span> writing(){\r\n  x= 2000;\r\n  y= 11;\r\n}\r\n\r\nvoid<\/span> reading(){ \r\n  std::cout << \"y: \"<\/span> << y << \" \"<\/span>;\r\n  std::cout << \"x: \"<\/span> << x << std::endl;\r\n}\r\n\r\nint<\/span> main(){\r\n  std::thread<\/span> thread1(writing);\r\n  std::thread<\/span> thread2(reading);\r\n  thread1.join();\r\n  thread2.join();\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
<\/span>Unsynchronized<\/span><\/h2>\n
The program has two data races and therefore has undefined behavior. Either the access to the variable x or the variable y is protected. Because the program has undefined behavior, each result is possible. In C++ jargon, that means a cruise missile can launch, or your PC catches fire. To me, it never happened, but…<\/p>\n
So, we can make no statement about the values of x and y.<\/p>\n
 \"undefinedEng\"<\/p>\n
<\/span>It’s not so bad<\/span><\/h3>\n
The known architectures guarantee that the access of an int<\/span> variable is atomic. But the int variable must be naturally aligned. Naturally aligned means that on a 32-bit architecture, the int variable must have an address divisible by 4. On a 64-bit architecture, divisible by 8. There is a reason why I mention this so explicitly. With C++11, you can adjust the alignment<\/a> of your data types.<\/p>\n
Once more. I don’t say that you should look at int variables as atomics. I only say that the compiler, in this case, guarantees more than the C++11 standard. But, if you use this rule, your program is not compliant with the C++ standard.<\/p>\n
This was my reasoning. Now we should look at what CppMem will say about the undefined behavior of the program.<\/p>\n<\/p>\n
<\/span>CppMem<\/span><\/h2>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13<\/pre>\n<\/td>\n
\n
int<\/span> main() {\r\n  int<\/span> x=0; \r\n  int<\/span> y=0;\r\n  {{{ { \r\n        x= 2000; \r\n        y= 11;\r\n      }\r\n  ||| {\r\n        y;\r\n        x;\r\n      }  \r\n  }}}\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The program is reduced to the bare minimum. You can easily define a thread with the curly braces (lines 4 and 12) and the pipe symbol (line 8). The additional curly braces in lines 4 and 7 or lines 8 and 11 define the work package of the thread. Because I’m not interested in the output of the variables x and y, I only read them in lines 9 and 10.<\/p>\n
That was the theory for CppMem. Now to the analysis.<\/p>\n
<\/span>Die Analysis<\/span><\/h2>\n
If I execute the program, CppMem complains in the red letters (1<\/span><\/strong>), that all four possible interleavings of threads are not race free. Only the first execution is consistent. Now I can use CppMem to switch between the four executions (2<\/span><\/strong>) and analyze the annotated graph (3<\/span><\/strong>).<\/p>\n
\"FullExcection\"<\/p>\n
We get the most out of CppMem from the graph. So I will dive more into the four graphs.<\/p>\n
<\/span>First execution<\/span><\/h3>\n
Which information can we draw from paragraph(3<\/strong><\/span>)?<\/p>\n
 \"first\"<\/p>\n
The graph nodes represent the program’s expressions, and the edges represent the expressions’ relations. I will refer in my explanation to the names (a) to (f). So, what can I derive from the annotations in this concrete execution?<\/p>\n