{"id":40363,"date":"2004-03-08T07:00:00","date_gmt":"2004-03-08T15:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2004\/03\/08\/c-scoped-static-initialization-is-not-thread-safe-on-purpose\/"},"modified":"2004-03-08T07:00:00","modified_gmt":"2004-03-08T15:00:00","slug":"c-scoped-static-initialization-is-not-thread-safe-on-purpose","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20040308-00\/?p=40363","title":{"rendered":"C++ scoped static initialization is not thread-safe, on purpose!"},"content":{"rendered":"

\n[Note<\/b>:\nAfter this article was written,\nthe C++ standard has been revised.\nStarting in C++11,\nscoped static initialization is now thread-safe,\nbut it comes with a cost: Reentrancy now invokes undefined behavior.]\n<\/p>\n

\nThe rule for static variables at block scope\n(as opposed to static variables with global scope)\nis that they are initialized the first time execution\nreaches their declaration.\n<\/p>\n

\nFind the race condition:\n<\/p>\n

\nint ComputeSomething()\n{\n  static int cachedResult = ComputeSomethingSlowly();\n  return cachedResult;\n}\n<\/pre>\n
\nThe intent of this code is\nto compute something expensive the first time the\nfunction is called, and then cache the result to be\nreturned by future calls to the function.\n<\/p>\n
\nA variation on this basic technique is\n\nis advocated by this web site to avoid the “static initialization\norder fiasco”<\/a>.\n(Said fiasco is well-described on that page so I encourage you\nto read it and understand it.)\n<\/p>\n
\nThe problem is that this code is not thread-safe.  Statics\nwith local scope are internally converted by the compiler into\nsomething like this:<\/p>\n
\nint ComputeSomething()\n{\n  static bool cachedResult_computed = false;\n  static int cachedResult;\n  if (!cachedResult_computed) {\n    cachedResult_computed = true;\n    cachedResult = ComputeSomethingSlowly();\n  }<\/font>\n  return cachedResult;\n}\n<\/pre>\n
\nNow the race condition is easier to see.\n<\/p>\n
\nSuppose two threads both call this function for the first time.\nThe first thread gets as far as setting\ncachedResult_computed = true,\nand then gets pre-empted.\nThe second thread now sees that cachedResult_computed is true\nand skips over the body of the “if” branch and returns\nan uninitialized variable.\n<\/p>\n
\nWhat you see here is not a compiler bug.\nThis behavior is required by the C++ standard<\/strong>.\n<\/p>\n
\nYou can write variations on this theme to create even worse\nproblems:\n<\/p>\n
\nclass Something { ... };\nint ComputeSomething()\n{\n  static Something s;\n  return s.ComputeIt();\n}\n<\/pre>\n
\nThis gets rewritten internally as\n(this time, using pseudo-C++):\n<\/p>\n
\nclass Something { ... };\nint ComputeSomething()\n{\n  static bool s_constructed = false;\n  static uninitialized Something s;\n  if (!s_constructed) {\n    s_constructed = true;\n    new(&s) Something; \/\/ construct it\n    atexit(DestructS);\n  }<\/font>\n  return s.ComputeIt();\n}\n\/\/ Destruct s at process termination\nvoid DestructS()\n{\n ComputeSomething::s.~Something();\n}<\/font>\n<\/pre>\n
\nNotice that there are multiple race conditions here.\nAs before, it’s possible for one thread to run ahead of the\nother thread and use “s” before it has been constructed.\n<\/p>\n
\nEven worse, it’s possible for the first thread to get\npre-empted immediately after testing s_constructed\nbut before<\/strong> setting it to “true”.\nIn this case, the object s gets double-constructed<\/strong>\nand double-destructed<\/strong>.\n<\/p>\n
\nThat can’t be good.\n<\/p>\n
\nBut wait, that’s not all.  Not look at what happens if you\nhave two<\/em> runtime-initialized local statics:\n<\/p>\n
\nclass Something { ... };\nint ComputeSomething()\n{\n  static Something s(0);\n  static Something t(1);\n  return s.ComputeIt() + t.ComputeIt();\n}\n<\/pre>\n
\nThis is converted by the compiler into the following\npseudo-C++:\n<\/p>\n
\nclass Something { ... };\nint ComputeSomething()\n{\n  static char constructed = 0;\n  static uninitialized Something s;\n  if (!(constructed & 1)) {\n    constructed |= 1;\n    new(&s) Something; \/\/ construct it\n    atexit(DestructS);\n  }\n  static uninitialized Something t;\n  if (!(constructed & 2)) {\n    constructed |= 2;\n    new(&t) Something; \/\/ construct it\n    atexit(DestructT);\n  }<\/font>\n  return s.ComputeIt() + t.ComputeIt();\n}\n<\/pre>\n
\nTo save space, the compiler placed the two\n“x_constructed” variables into a bitfield.\nNow there are multiple\nnon-interlocked<\/strong>\nread-modify-store operations on the variable\n“constructed”.\n<\/p>\n
\nNow consider what happens if one thread\nattempts to execute “constructed |= 1”\nat the same time another thread attempts\nto execute “constructed |= 2”.\n<\/p>\n
\nOn an x86, the statements likely assemble into<\/p>\n
\n  or constructed, 1\n...\n  or constructed, 2\n<\/pre>\n
without any “lock” prefixes.\nOn multiprocessor machines, it is possible\nfor the two stores both to read the old value\nand clobber each other with conflicting values.\n<\/p>\n
\nOn ia64 and alpha, this clobbering is much more\nobvious since they do not have a single\nread-modify-store instruction; the three\nsteps must be explicitly coded:\n<\/p>\n
\n  ldl t1,0(a0)     ; load\n  addl t1,1,t1     ; modify\n  stl t1,1,0(a0)   ; store\n<\/pre>\n
\nIf the thread gets pre-empted between the load\nand the store, the value stored may no longer\nagree with the value being overwritten.\n<\/p>\n
\nSo now consider the following insane sequence of execution:\n<\/p>\n
    \n
  • Thread A tests “constructed” and finds it zero and prepares\n    to set the value to 1, but it gets pre-empted.<\/p>\n
  • Thread B enters the same function, sees “constructed” is zero\n    and proceeds to construct both “s” and “t”, leaving\n    “constructed” equal to 3.<\/p>\n
  • Thread A resumes execution and completes its load-modify-store\n    sequence, setting “constructed” to 1, then constructs “s”\n    (a second time).<\/p>\n
  • Thread A then proceeds to construct “t” as well (a second time)\n    setting “constructed” (finally) to 3.\n<\/ul>\n
    \nNow, you might think you can wrap the runtime initialization\nin a critical section:\n<\/p>\n
    \nint ComputeSomething()\n{\n EnterCriticalSection(...);\n static int cachedResult = ComputeSomethingSlowly();\n LeaveCriticalSection(...);\n return cachedResult;\n}\n<\/pre>\n
    \nBecause now you’ve placed the one-time initialization inside\na critical section and made it thread-safe.\n<\/p>\n
    \nBut what if the second call comes from within the same thread?\n(“We’ve traced the call; it’s coming from inside the thread!”)\nThis can happen if ComputeSomethingSlowly() itself calls\nComputeSomething(), perhaps indirectly.\nSince that thread already owns the critical section, the code\nenter it just fine and you once again\nend up returning an uninitialized variable.\n<\/p>\n
    \nConclusion: When you see runtime initialization of a local static\nvariable, be very concerned.<\/p>\n","protected":false},"excerpt":{"rendered":"
    How the design of the C++ language subverts thread safety.<\/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-40363","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    How the design of the C++ language subverts thread safety.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/40363","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=40363"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/40363\/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=40363"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=40363"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=40363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}