{"id":99405,"date":"2018-08-03T07:00:00","date_gmt":"2018-08-03T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=99405"},"modified":"2019-03-13T00:37:50","modified_gmt":"2019-03-13T07:37:50","slug":"20180803-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180803-00\/?p=99405","title":{"rendered":"Creating an awaitable lock for WinJS and JavaScript Promises"},"content":{"rendered":"

Last time<\/a>, we created an awaitable lock for C++ PPL tasks. Let’s do the same thing for WinJS Promises (because I needed one of those too). <\/p>\n

\nvar AwaitableLock = WinJS.Class.define(function AwaitableLock() {\n  this._locked = false;\n  this._p = null;\n  this._c = null;\n}, {\n  waitAsync: function waitAsync() {\n    if (!this._locked) {\n      \/\/ Lock is available. Acquire it.\n      this._locked = true;\n      return WinJS.Promise.wrap();\n    }\n\n    \/\/ Lock is not available.\n    var self = this;\n    if (!this._p) {\n      \/\/ Create a promise that completes when the lock is released.\n      this._p = new WinJS.Promise(function (c) { self._c = c; });\n    }\n\n    \/\/ Return a promise that waits for the lock to be released\n    \/\/ and then retries the wait.\n    return this._p.then(function () { return self.waitAsync(); });\n  },\n\n  release: function release() {\n    this._locked = false;\n    var c = this._c;\n    this._p = null;\n    this._c = null;\n\n    \/\/ Complete any promise that was waiting for release.\n    c && c();\n  }\n});\n<\/pre>\n
Since JavaScript is single-threaded, we don’t have to worry about concurrency, so we don’t need a mutex to guard our state variables. If the lock is available, then acquire it and return a completed promise. <\/p>\n
Otherwise, we have to create a promise. The WinJS.Promise<\/code> constructor takes a function which in turn receives a few parameters, although we use only c<\/code> here. The c<\/code> parameter is itself a function that our code can call to complete the promise. All we do is save that callback in the _c<\/code> property so that we can complete the promise later. To avoid having to remember multiple completion callbacks, we create this promise once and cache it in the _p<\/code> property. <\/p>\n
We then chain a continuation on that newly-created promise that restarts the waitAsync<\/code>, and return the resulting promise. <\/p>\n
When the lock is released, we clear the saved completion and promise (thereby resetting the lock object to its unlocked state), and if there is a completion function, we call it. This completes the promise we created in waitAsync<\/code>, which means that each of them will race to waitAsync<\/code> and retry the acquisition. <\/p>\n
There is a subtlety here: We reset the lock object completely before calling the completion. The completion is going to attempt to re-acquire the lock object, and we don’t want the reentrant call to see a lock object in an inconsistent state. To avoid that, we capture the completion callback into a local c<\/code>, and then after the lock object has been reset, we call the callback if necessary. <\/p>\n
We can use ES6 function arrow notation to simplify this code, but if we’re going to do that, we may as well go all the way and use ES6 native promises. <\/p>\n
\nvar AwaitableLock = WinJS.Class.define(function AwaitableLock() {\n  this._locked = false;\n  this._p = null;\n  this._c = null;\n}, {\n  waitAsync()<\/font> {\n    if (!this._locked) {\n      \/\/ Lock is available. Acquire it.\n      this._locked = true;\n      return Promise.resolve()<\/font>;\n    }\n\n    \/\/ Lock is not available.\n    if (!this._p) {\n      \/\/ Create a promise that completes when the lock is released.\n      this._p = new Promise<\/font>(c => this._c = c<\/font>);\n    }\n\n    return this._p.then(() => this.waitAsync()<\/font>);\n  },\n\n  release()<\/font> {\n    this._locked = false;\n    var c = this._c;\n    this._p = null;\n    this._c = null;\n\n    \/\/ Complete any promise that was waiting for release.\n    c && c();\n  }\n});\n<\/pre>\n
The ES6 Promise method for creating an already-completed promise is called resolve<\/code>, as opposed to wrap<\/code>, which is what WinJS.Promise<\/code> calls it. The Promise constructor is the same, so we didn’t have to make any changes there aside from arrowizing the functions. Arrowizing is convenient because it preserves this<\/code> inside the lambda, which saves us the trouble of having to create a separate self<\/code> variable. <\/p>\n
And since we’re abandoning WinJS, we may as well go all the way and define the class using ES6’s native class declaration syntax. <\/p>\n
\nclass AwaitableLock {<\/font>\n  constructor()<\/font> {\n    this._locked = false;\n    this._p = null;\n    this._c = null;\n  }\n\n  waitAsync()<\/font> {\n    if (!this._locked) {\n      \/\/ Lock is available. Acquire it.\n      this._locked = true;\n      return Promise.resolve();\n    }\n\n    \/\/ Lock is not available.\n    if (!this._p) {\n      \/\/ Create a promise that completes when the lock is released.\n      this._p = new Promise(c => this._c = c);\n    }\n\n    return this._p.then(() => this.waitAsync());\n  }\n\n  release()<\/font> {\n    this._locked = false;\n    var c = this._c;\n    this._p = null;\n    this._c = null;\n\n    \/\/ Complete any promise that was waiting for release.\n    c && c();\n  }\n}\n<\/pre>\n
Exercise<\/b>: Why couldn’t we arrowize the constructor? <\/p>\n
Exercise 2<\/b>: Why did we set the member variables dynamically in the constructor instead of defining them statically on the prototype? <\/p>\n
Exercise 3<\/b>: Why couldn’t I have precalculated the .then<\/code> of the promise? <\/p>\n
\n\/\/ Code in italics is wrong - but why?\nAwaitableLock.prototype.waitAsync = function waitAsync() {\n  if (!this._locked) {\n    \/\/ Lock is available. Acquire it.\n    this._locked = true;\n    return Promise.resolve();\n  }\n\n  \/\/ Lock is not available.\n  if (!this._p) {\n    \/\/ Create a promise that completes when the lock is released\n    \/\/ and then retries the wait.\n    this._p = new Promise(c => this._c = c).then(() => this.waitAsync())<\/font>;\n  }\n\n  return this._p<\/font>;\n}<\/i>\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Rolling onward.<\/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-99405","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Rolling onward.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99405","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=99405"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99405\/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=99405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=99405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=99405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}