{"id":102463,"date":"2019-05-01T07:00:00","date_gmt":"2019-05-01T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102463"},"modified":"2019-06-06T17:47:12","modified_gmt":"2019-06-07T00:47:12","slug":"20190501-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190501-00\/?p=102463","title":{"rendered":"Async-Async: Consequences for parameters to parallel asynchronous calls"},"content":{"rendered":"

Last time<\/a>, we learned about a feature known as Async-Async which makes asynchronous operations even more asynchronous by pretending that they started before they actually did. The introduction of Async-Async is intended to be transparent to both the client and the server, provided they were following the rules to begin with. Of course, if you weren’t following the rules, then you may notice some side effects.<\/p>\n

From the client side, it means that you cannot mutate the parameters of an asynchronous operation until the operation completes. This was never permitted to begin with, but people sometimes got away with it because they “knew” that certain parameters were consumed before the initial method returned an asynchronous operation.<\/p>\n

\/\/ Code in italics is wrong.\r\n\r\n\/\/ Create three widgets in parallel.\r\nvar options = new WidgetOptions();\r\n\r\n\/\/ Create a blue widget.\r\noptions.Color = Colors.Blue;\r\nvar task1 = Widget.CreateAsync(options);\r\n\r\n\/\/ Create another blue widget.\r\nvar task2 = Widget.CreateAsync(options);\r\n\r\n\/\/ Create a red widget.\r\noptions.Color = Colors.Red;\r\nvar task3 = Widget.CreateAsync(options);<\/i>\r\n\r\n\/\/ Wait for all the widgets to be created.\r\nawait Task.WhenAll(task1, task2, task3);\r\n\r\n\/\/ Get the widgets.\r\nvar widget1 = task1.Result;\r\nvar widget2 = task2.Result;\r\nvar widget3 = task3.Result;\r\n<\/pre>\n
This code “knows” that the Widget.<\/code>Create\u00adAsync<\/code> method looks at the options.Color<\/code> before<\/i> it returns with an IAsync\u00adOperation<\/code>. It therefore “knows” that any changes to the options<\/code> after Widget.<\/code>Create\u00adAsync<\/code> returns will not have any effect on the widget being created, so it goes ahead and reconfigures the options<\/code> object so it can be used for the third widget.<\/p>\n
This code does not work when Async-Async is enabled. The calls to Widget.<\/code>Create\u00adAsync<\/code> will return immediately with fake IAsync\u00adOperation<\/code>s, while the real calls to Widget.<\/code>Create\u00adAsync<\/code> are still in progress. As we saw earlier, the result of the real call to Widget.<\/code>Create\u00adAsync<\/code> will be connected to the fake IAsync\u00adOperation<\/code> so that you get the result you want, but the timing has changed to improve performance. If the above code manages to change the options.<\/code>Color<\/code> to red before one of the first two real calls to Widget.<\/code>Create\u00adAsync<\/code> reads the options, then one or both of the first two widgets will end up red rather than blue.<\/p>\n
This is basically a case of violating one of the  basic ground rules for programming<\/a>: You cannot change a parameter while the function call is in progress. It’s just that for asynchronous operations, the “in progress” extends all the way through to the completion of the asynchronous operation.<\/p>\n
It’s fine to kick off multiple asynchronous operations. Just make sure they don’t interfere with each other.<\/p>\n
\/\/ Create three widgets in parallel.\r\nvar options = new WidgetOptions();\r\n\r\n\/\/ Create a blue widget.\r\noptions.Color = Colors.Blue;\r\nvar task1 = Widget.CreateAsync(options);\r\n\r\n\/\/ Create another blue widget.\r\nvar task2 = Widget.CreateAsync(options);\r\n\r\n\/\/ Create a red widget.\r\noptions = new WidgetOptions();<\/span>\r\noptions.Color = Colors.Red;\r\nvar task3 = Widget.CreateAsync(options);\r\n\r\n\/\/ Wait for all the widgets to be created.\r\nawait Task.WhenAll(task1, task2, task3);\r\n\r\n\/\/ Get the widgets.\r\nvar widget1 = task1.Result;\r\nvar widget2 = task2.Result;\r\nvar widget3 = task3.Result;\r\n<\/pre>\n
This time, we create a new Widget\u00adOptions<\/code> object for the final call to Widget.\u00adCreate\u00adAsync<\/code>. That way, each call to Widget.<\/code>Create\u00adAsync<\/code> gets an options<\/code> object that is stable for the duration of the call. It’s okay to share the options<\/code> object among multiple calls (like we did for the first two blue widgets), but don’t change them while there is still an asynchronous operation that is using them.<\/p>\n
Of course, once the operation completes, then you are welcome to do whatever you like to the options<\/code>, since the operation isn’t using them any more.<\/p>\n
\/\/ Create three widgets in series.\r\nvar options = new WidgetOptions();\r\n\r\n\/\/ Create a blue widget.\r\noptions.Color = Colors.Blue;\r\nvar widget1 = await Widget.CreateAsync(options);\r\n\r\n\/\/ Create another blue widget.\r\nvar widget2 = await Widget.CreateAsync(options);\r\n\r\n\/\/ Create a red widget.\r\noptions.Color = Colors.Red;\r\nvar widget3 = await Widget.CreateAsync(options);\r\n<\/pre>\n
In this case, we created the widgets in series. We changed the options<\/code> after awaiting the result of the operation, so we know that the operation is finished and it is safe to modify the options<\/code> for a new call.<\/p>\n
Next time, we’ll look at another consequence of Async-Async.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Keep those parameter stable.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-102463","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Keep those parameter stable.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102463","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=102463"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102463\/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=102463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}