{"id":243,"date":"2014-08-14T07:00:00","date_gmt":"2014-08-14T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/08\/14\/customers-not-getting-the-widgets-they-paid-for-if-they-click-too-fast-or-in-c-the-operator-is-not-merely-not-guaranteed-to-be-atomic-it-is-guaranteed-not-to-be-atomic\/"},"modified":"2014-08-14T07:00:00","modified_gmt":"2014-08-14T07:00:00","slug":"customers-not-getting-the-widgets-they-paid-for-if-they-click-too-fast-or-in-c-the-operator-is-not-merely-not-guaranteed-to-be-atomic-it-is-guaranteed-not-to-be-atomic","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20140814-00\/?p=243\/","title":{"rendered":"Customers not getting the widgets they paid for if they click too fast -or- In C#, the += operator is not merely not guaranteed to be atomic, it is guaranteed not to be atomic"},"content":{"rendered":"

In the C# language, operation\/assignment such as +=<\/code>\nare explicitly not<\/i> atomic.\nBut you already knew this, at least for properties.\n<\/p>\n

\nRecall that properties are syntactic sugar for method calls.\nA property declaration\n<\/p>\n

\nstring Name { get { ... } set { ... } }\n<\/pre>\n
\nis internally converted to the equivalent of<\/p>\n
\nstring get_Name() { ... }\nvoid set_Name(string value) { ... }\n<\/pre>\n
\nAccessing a property is similarly transformed.\n<\/p>\n
\n\/\/ o.Name = \"fred\";\no.put_Name(\"fred\");\n\/\/ x = o.Name;\nx = o.get_Name();\n<\/pre>\n
\nNote that the only operations you can provide for properties\nare get<\/code> and set<\/code>.\nThere is no way of customizing any other operations, like\n+=<\/code>.\nTherefore, if you write\n<\/p>\n
\no.Name += \", Jr.\";\n<\/pre>\n
\nthe compiler has no choice but to convert it to\n<\/p>\n
\no.put_Name(o.get_Name() + \", Jr.\");\n<\/pre>\n
\nIf all you have is a hammer, everything needs to be converted to a nail.\n<\/p>\n
\nSince the read and write are explicitly decoupled, there is naturally\na race condition here.\nThe underlying property may change value in between the time you read\nthe old value and the time you write the new value.\n<\/p>\n
\nBut there are extra subtleties here.\nLet’s dig in.\n<\/p>\n
\nThe rule for operators like +=<\/code> are spelled out in\n\nSection 14.3.2: Compound Assignment<\/i><\/a>:\n<\/p>\n
\n[T]he operation is evaluated as x = x op y,\nexcept that x is evaluated only once.\n<\/p><\/blockquote>\n
\n(There is some discussion of what “evaluated only once” means,\nbut that’s not important here.)\n<\/p>\n
\nThe subtleties lurking in that one sentence\nare revealed when you see how that sentence interacts\nwith other rules in the language.\n<\/p>\n
\nNow, you might say,\n“Sure, it’s not atomic, but my program is single-threaded,\nso this should never affect me.”\n<\/p>\n
\nActually, you can get bitten by this even in single-threaded programs.\nLet’s try it:\n<\/p>\n
\nclass Program\n{\n static int x = 0;\n static int f()\n {\n  x = x + 10;\n  return 1;\n }\n public static void Main()\n {\n  x += f();\n  System.Console.WriteLine(x);\n }\n}\n<\/pre>\n
\nWhat does this program print?\n<\/p>\n
\nYou might naïvely think that it prints 11<\/code>\nbecause x<\/code> is incremented by 1 by Main<\/code>\nand incremented by 10 in f<\/code>.\n<\/p>\n
\nBut it actually prints 1.\n<\/p>\n
\nWhat happened here?\n<\/p>\n
\nRecall that C# uses\n\nstrict left-to-right evaluation order<\/a>.\nTherefore, the order of operations in the evaluation of\nx += f()<\/code> is\n<\/p>\n
    \n
  1. Rewrite as x = x + f()<\/code>.\n
  2. Evaluate both sides of the =<\/code> operator, left to right.\n
      \n
    1. Left hand side of assignment: Find the variable x<\/code>.\n
    2. Right hand side of assignment:\n
        \n
      1. Evaluate both sides of the +<\/code> operator, left to right.\n
          \n
        1. Evaluate x<\/code>.\n
        2. Evaluate f()<\/code>.\n            <\/ol>\n
        3. Add together the results of steps 2b(i)1 and 2b(i)2.\n        <\/ol>\n<\/ol>\n
        4. Take the result of step 2b(ii) and assign it to\n        the variable x<\/code> found in step 2a.\n<\/ol>\n
          \nThe thing to notice is that a lot of things can happen between step\n2b(i)1 (evaluating the old value of x<\/code>),\nand step 3 (assigning the final result to x<\/code>).\nSpecifically,\nwe shoved a whole function call in there: f()<\/code>.\n<\/p>\n
          \nIn our case, the function\nf()<\/code> also modifies x<\/code><\/i>.\nThat modification takes place after we already captured the\nvalue of x<\/code> in step 2b(i)1.\nWhen we get around to adding the values in step 2b(ii),\nwe don’t realize that the values are out of date.\n<\/p>\n
          \nLet’s step through this evaluation in our example.\n<\/p>\n
            \n
          1. Rewrite as x = x + f()<\/code>.\n
          2. Evaluate both sides of the =<\/code> operator, left to right.\n
              \n
            1. Left hand side of assignment: Find the variable x<\/code>.\n
            2. Right hand side of assignment:\n
                \n
              1. Evaluate both sides of the +<\/code> operator, left to right.\n
                  \n
                1. Evaluate x<\/code>. The result is 0.\n
                2. Evaluate f()<\/code>. The result is 1.\n                It also happens that x<\/code> is modified as a\n                side-effect.\n            <\/ol>\n
                3. Add together the results of steps 2b(i)1 and 2b(i)2.\n            In this case, 0 + 1 = 1.\n        <\/ol>\n<\/ol>\n
                4. Take the result of step 2b and assign it to\n        the variable x<\/code> found in step 2a.\n        In this case, assign 1 to x<\/code>.\n<\/ol>\n
                  \nThe modification to x<\/code> that took place in f<\/code>\nwas clobbered by the assignment operation that completed the\n+=<\/code> sequence.\nAnd this behavior is not just in some weird\n“undefined behavior” corner of the language specification.\nThe language specification explicitly requires<\/i> this behavior.\n<\/p>\n
                  \nNow, you might say,\n“Okay, I see your point, but this is clearly an unrealistic example,\nbecause nobody would write code this weird.”\n<\/p>\n
                  \nMaybe you don’t intentionally write code this weird, but you can\ndo it accidentally.\nAnd this is particularly true if you are using the new\nawait<\/code> keyword,\nbecause an await<\/code> means,\n“Hey, like, put my function on hold and do other stuff for a while.\nWhen the thing I’m awaiting is ready,\nthen resume execution of my function.”\nAnd that “do other stuff for a while”\nmight change x<\/code>.\n<\/p>\n
                  \nSuppose that you have a button in your application called Buy More<\/i>.\nWhen the user clicks it, they can buy more widgets.\nLet’s assume that the Buy­More­Async<\/code>\nfunction return the\nnumber of items bought. (If the user cancels the purchase\nit returns zero.)\n<\/p>\n
                  \n\/\/ Suppose the user starts with 100 widgets.\nasync void BuyMoreButton_OnClick()\n{\n TotalWidgets += await BuyMoreAsync();\n Inventory.Text = string.Format(\"You have {0} widgets.\",\n                                TotalWidgets);\n}\nasync Task<int> BuyMoreAsync()\n{\n int quantity = QuickPurchase.IsChecked ? 1\n                                        : await GetQuantityAsync();\n if (quantity != 0) {\n  if (await DebitAccountAsync(quantity * PricePerWidget)) {\n   return quantity;\n  }\n }\n return 0; \/\/ user bought no items\n}\n<\/pre>\n
                  \nYou receive a bug report that you track back to the fact that\nTotal­Widgets<\/code> does not match the\nnumber of widgets purchased.\nIt affects only people who checked the quick purchase<\/i> box,\nand only people purchasing from overseas.\n<\/p>\n
                  \nHere’s what is going on.\n<\/p>\n
                  \nThe user clicks the Buy More<\/i> button,\nand they have Quick Purchase<\/i> enabled.\nThe Buy­More­Async<\/i> function tries to\ndebit the account for the price of one widget.\n<\/p>\n
                  \nWhile waiting for the server to process the transaction,\nthe user gets impatient and clicks Buy More<\/i> a second time.\nThis triggers a second task to debit the account for the\nprice of one widget.\n<\/p>\n
                  \nOkay, so you now have two tasks running,\neach processing one of the clicks.\nIn theory, the worst case is that the user accidentally\nbuys two widgets,\nbut in practice…\n<\/p>\n
                  \nThe first Debit­Account­Async<\/code> task completes,\nand Buy­More­Async<\/code> returns 1,\nwhich is then added to the value of\nTotal­Widgets<\/code> at the time the button was clicked,\nas we discussed above.\nAt the time the button was clicked the first time, the number of\nwidgets was 100,\nso the total number of widgets is now 101.\n<\/p>\n
                  \nThe second Debit­Account­Async<\/code> task completes,\nand Buy­More­Async<\/code> returns 1,\nwhich is then added to the value of Total­Widgets<\/code>\nat the time the button was clicked,\nas we discussed above.\nWhen the button was clicked the second time,\nthe number of widgets was still 100<\/i>.\nWe set the total widget count to 100 + 1 = 101<\/code>.\n<\/p>\n
                  \nResult: The user paid for two widgets but got only one.\n<\/p>\n
                  \nThe fix for this is to explicitly move waiting for the\npurchase to complete outside of the compound assignment.\n<\/p>\n
                  \n int quantity = await BuyMoreAsync();\n TotalWidgets += quantity;\n<\/pre>\n
                  \nNow, the await<\/code> is outside the compound assignment\nso that the value of Total­Widgets<\/code> is not captured\nprematurely.\nWhen the purchase completes, we update Total­Widgets<\/code>\nwithout interruption from any async operations.\n<\/p>\n
                  \n(You probably also should fix the program so it disables the\nBuy More<\/i> button while a transaction is in progress,\nto avoid the impatient user ends up making an accidental double\npurchase<\/i> problem. The above fix merely gets rid of the\nuser pays for two items and gets only one<\/i> problem.)\n<\/p>\n
                  \nLike\n\nclosing around the loop control variable<\/a>,\nthis is the sort of subtle change that should be well-commented\nso that somebody doesn’t “fix” it in a well-intentioned but\nmisguided attempt to remove unnecessary variables.\nThe purpose of the variable is not to break an expression into two\nbut rather to force a particular order of evaluation:\nYou want to to finish the purchase operation before starting to\nupdate the widget count.<\/p>\n","protected":false},"excerpt":{"rendered":"
                  In the C# language, operation\/assignment such as += are explicitly not atomic. But you already knew this, at least for properties. Recall that properties are syntactic sugar for method calls. A property declaration string Name { get { … } set { … } } is internally converted to the equivalent of string get_Name() { […]<\/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-243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
                  In the C# language, operation\/assignment such as += are explicitly not atomic. But you already knew this, at least for properties. Recall that properties are syntactic sugar for method calls. A property declaration string Name { get { … } set { … } } is internally converted to the equivalent of string get_Name() { […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/243","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=243"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/243\/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=243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}