4 ms·

JS async is lock free though.

ackfoobar 4y ago
You will need locks if you need mutual exclusion across an `await`.
cogman10 4y ago
JS has an uber lock. JS has a strict requirement that only one thread can run javascript code. That means that whenever you get to that `await` block, you've effectively established a whole application lock which prevents other awaits from proceeding (until your code yields). In otherwords JS isn't lock free, it's got 1 really big lock that covers all user code. If you really wanted to, you could simulate this behavior in threaded languages by having a global lock you acquire before you run anything. It's the python GIL problem [1] Languages like kotlin, rust, C++, or C# with async/await MUST concern themselves with locks because they don't acquire whole application locks anytime they run a sliver of code. [1] https://realpython.com/python-gil/ https://realpython.com/python-gil/
- SemanticStrengh 4y ago
  Great explanation in general except web workers are a thing and sharedarraybuffer allow shared memory between them. Thats why js has atomics. Although while js can have conçurent races via shared memory, it doesn't expose locks IIRC? If so that's bad
  - cogman10 4y ago
    Web workers are certainly weird... and it's generally best to ignore them :D But if you don't, then yeah, you sort of run right into the need for an actual lock since you can have shared memory in concurrently executing interpreters. Entire: Web Lock [1] Specifically designed to resolve this issue. In typical JS programming this is not an issue, but if you are trying to really abuse that javascript VM then this is the way you'd do it. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...
    - SemanticStrengh 4y ago
      Oh thank u web locks are a thing then. Well in all seriousness there are many valid uses for web workers, e.g. For offline processing of localstorage

You will need locks if you need mutual exclusion across an `await`.

JS has an uber lock. JS has a strict requirement that only one thread can run javascript code. That means that whenever you get to that `await` block, you've effectively established a whole application lock which prevents other awaits from proceeding (until your code yields). In otherwords JS isn't lock free, it's got 1 really big lock that covers all user code. If you really wanted to, you could simulate this behavior in threaded languages by having a global lock you acquire before you run anything. It's the python GIL problem [1] Languages like kotlin, rust, C++, or C# with async/await MUST concern themselves with locks because they don't acquire whole application locks anytime they run a sliver of code. [1] https://realpython.com/python-gil/ https://realpython.com/python-gil/

SemanticStrengh 4y ago
Great explanation in general except web workers are a thing and sharedarraybuffer allow shared memory between them. Thats why js has atomics. Although while js can have conçurent races via shared memory, it doesn't expose locks IIRC? If so that's bad
- cogman10 4y ago
  Web workers are certainly weird... and it's generally best to ignore them :D But if you don't, then yeah, you sort of run right into the need for an actual lock since you can have shared memory in concurrently executing interpreters. Entire: Web Lock [1] Specifically designed to resolve this issue. In typical JS programming this is not an issue, but if you are trying to really abuse that javascript VM then this is the way you'd do it. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...
  - SemanticStrengh 4y ago
    Oh thank u web locks are a thing then. Well in all seriousness there are many valid uses for web workers, e.g. For offline processing of localstorage