{"id":98365,"date":"2018-03-28T07:00:00","date_gmt":"2018-03-28T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98365"},"modified":"2019-03-13T00:51:19","modified_gmt":"2019-03-13T07:51:19","slug":"20180328-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180328-00\/?p=98365","title":{"rendered":"When I memcpy a struct into a std::atomic of that struct, why does the result not match?"},"content":{"rendered":"

Consider the following code: <\/p>\n

\n\/\/ Code in italics is wrong.\n\nstruct Point3D { float x, y, z; };\n\nstd::atomic<Point3D> currentPoint;\n\nbool LoadCurrentPointFromFile(HANDLE file)\n{\n DWORD actualBytesRead;\n if (!ReadFile(file, &currentPoint, sizeof(Point3D),\n               &actualBytesRead, nullptr)) return false;\n if (actualBytesRead != sizeof(Point3D)) return false;\n return true;\n}<\/i>\n<\/pre>\n
This code tries to load a Point3D<\/code> structure from a file directly into a std::atomic<\/code>. However, the customer found that the results were not properly loaded and suspected there may a bug in the Read­File<\/code> function, because the value that should have been in the z<\/code> member ended up in y<\/code>, the value that should have been in the y<\/code> member ended up in x<\/code>, and the value that should have been in the x<\/code> member wasn’t loaded at all. <\/p>\n
The Read­File<\/code> function is working fine. What’s wrong is that you aren’t using the std::atomic<\/code> variable properly. <\/p>\n
The contents of a std::atomic<\/code> variable are not directly accessible. You have to use methods like store<\/code> and load<\/code>. There are operator overloads which make atomic variables appear to be regular variables, but at no point can you get the address of the underlying Point3D<\/code> storage. <\/p>\n
Processors have restrictions on the sizes of operands on which they can natively perform atomic operations. Some restrictions apply to the size of the operand: Most processors do not support atomic operations on 12-byte objects, and it’s not reasonable to expect a processor to be able to perform an atomic operation on a memory object that is megabytes in size, after all. Some restrictions are based on layout, such as whether the object is suitably aligned. <\/p>\n
In the cases where the object cannot be managed atomically by the processor, the standard library steps in and adds a lock, and operations on the atomic variable take the lock to ensure that the operation is atomic. The reason everything is shifted is that the code took the address of the atomic variable itself, which includes the intenral lock, and the value you intended to read into x<\/code> didn’t vanish. It overwrote the lock! <\/p>\n
Access to the contents of the atomic variable must be done by the appropriate methods on the atomic variable. <\/p>\n
\nbool LoadCurrentPointFromFile(HANDLE file)\n{\n DWORD actualBytesRead;\n Point3D point;<\/font>\n if (!ReadFile(file, &point<\/font>, sizeof(Point3D),\n               &actualBytesRead, nullptr)) return false;\n if (actualBytesRead != sizeof(Point3D)) return false;\n currentPoint.store(point);<\/font>\n return true;\n}\n<\/pre>\n
There’s a presentation from CppCon 2017 that covers std::atomic<\/code> from start to finish<\/a>, including performance characteristics. I’m going to consider this video to be homework, because next time I’m going to chatter about it<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
You’re storing it wrong.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-98365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You’re storing it wrong.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=98365"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98365\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=98365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=98365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=98365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}