{"id":9853,"date":"2011-08-19T07:00:00","date_gmt":"2011-08-19T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2011\/08\/19\/why-are-the-alignment-requirements-for-slist_entry-so-different-on-64-bit-windows\/"},"modified":"2011-08-19T07:00:00","modified_gmt":"2011-08-19T07:00:00","slug":"why-are-the-alignment-requirements-for-slist_entry-so-different-on-64-bit-windows","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20110819-00\/?p=9853","title":{"rendered":"Why are the alignment requirements for SLIST_ENTRY so different on 64-bit Windows?"},"content":{"rendered":"

The Interlocked­Push­Entry­SList<\/code> function stipulates that all list items must be aligned on a MEMORY_ALLOCATION_ALIGNMENT<\/code> boundary<\/a>. For 32-bit Windows, MEMORY_ALLOCATION_ALIGNMENT<\/code> is 8, but the SLIST_ENTRY<\/code> structure itself does not have a DECLSPEC_ALIGN(8)<\/code> attribute. Even more confusingly, the documentation for SLIST_ENTRY<\/code><\/a> says that the 64-bit structure needs to be 16-byte aligned but says nothing about the 32-bit structure. So what are the memory alignment requirements for a 32-bit SLIST_ENTRY<\/code>, 8 or 4?\n It’s 8. No, 4. No wait, it’s both.\n Officially, the alignment requirement is 8. Earlier versions of the header file did not stipulate 8-byte alignment, and changing the declaration would have resulted in existing structures which (inadvertently) misaligned the field changing size and layout when the new requirement was imposed. So the 32-bit structure was sort-of grandfathered in. You should still align it on 8-byte boundaries, but the header file doesn’t enforce it to avoid breaking existing code.\n Fortunately, when the 64-bit version was introduced, the proper alignment directive was introduced right off the bat. How about that: sometimes Microsoft learns from its mistakes after all.\n Why are the alignment requirements greater than the natural word size? To avoid the ABA problem<\/a>. A standard workaround for the ABA problem is to append additional information (a “tag”) to the pointer so that when the value changes from B back to A, the tag ensures that the second A still looks different from the first one. Many CPU architectures have a “double-pointer-sized atomic compare-and-swap” instruction, and some of them have the additional requirement that the double-pointer needs to be on a double-pointer boundary (8 bytes for 32-bit pointers and 16 bytes for 64-bit pointers).\n “But wait, the double-pointer compare-and-swap is used on the SLIST_HEADER<\/code>, not on the SLIST_ENTRY<\/code>. Why does the SLIST_ENTRY<\/code> need to be double-pointer aligned, too?”<\/p>\n

While it’s true that many CPU architectures have a “double-pointer-sized atomic compare-and-swap” instruction, some support only a “pointer-sized atomic compare-and-swap”. For example, the original AMD64 architecture did not have a CMPXCHG16B instruction<\/a>; the largest data size for an atomic compare-and-swap was 8 bytes. As a result, the Slist functions need to pack a 64-bit pointer, a list depth, and<\/i> tag information into a single 64-bit value. One of the tricks they used was imposing a memory alignment of 16 bytes. This freed up four bits in the pointer for use as a tag. <\/p>\n","protected":false},"excerpt":{"rendered":"

The Interlocked­Push­Entry­SList function stipulates that all list items must be aligned on a MEMORY_ALLOCATION_ALIGNMENT boundary. For 32-bit Windows, MEMORY_ALLOCATION_ALIGNMENT is 8, but the SLIST_ENTRY structure itself does not have a DECLSPEC_ALIGN(8) attribute. Even more confusingly, the documentation for SLIST_ENTRY says that the 64-bit structure needs to be 16-byte aligned but says nothing about the 32-bit structure. […]<\/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-9853","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

The Interlocked­Push­Entry­SList function stipulates that all list items must be aligned on a MEMORY_ALLOCATION_ALIGNMENT boundary. For 32-bit Windows, MEMORY_ALLOCATION_ALIGNMENT is 8, but the SLIST_ENTRY structure itself does not have a DECLSPEC_ALIGN(8) attribute. Even more confusingly, the documentation for SLIST_ENTRY says that the 64-bit structure needs to be 16-byte aligned but says nothing about the 32-bit structure. […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/9853","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=9853"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/9853\/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=9853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=9853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=9853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}