4 ms·

> two sequential lines of code are no longer two truly sequential instructions I've done a lot of async/await and I really can't think of any situations where

> two sequential lines of code are no longer two truly sequential instructions I've done a lot of async/await and I really can't think of any situations where this has been a concern for me. If you're mutating state in method calls without explicitly passing it around, that might be an issue but that's a deeper design issue IMHO.

PetahNZ 7y ago
One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.
- kbenson 7y ago
  Seems like you should be able to build a lock mechanism fairly simply with async/await, but I agree, it would be nice if it was a built in primitive. It does feel a little silly to implement a lock function when the engine much be using one to support its async functionality in the first place, so you're introducing a lot of inefficiency.
  - Arelius 7y ago
    I don't think it's true that the engine must be using a mutex to support it's async functionality. Or that it is true that an OS mutex will be any more efficient than alternative solutions. A mutex really can only exist to serialize async code. If you want it serialized that likely means that code shouldn't be async in the first place.
    - kbenson 7y ago
      You're right that it may not be required for the async functionality (especially since lock-free schedulers exist, and the engine is basically a single processor scheduler for processes). I do think it's likely in use other places though, just because it's much easier to write correct code with one.
  - matharmin 7y ago
    Implementing a mutex is very simple and efficient in JavaScript - probably much lower overhead than the Promises itself.
- Arelius 7y ago
  Do you really want to block all of your http calls on the result of the prior call in the off-chance that they might share a result just so you can only cache the results and not the promises? The reason we don't have a mutex in javascript is that there are better solutions to the problems it solves.
  - hombre_fatal 7y ago
    Maybe I don't understand your response, but a map of promises to handle parallel in-flight requests for the same resource (which the grandparent pitched) is basically the most elegant yet simple solution to this common problem. I don't really see how it's a mutex though, you're just returning the same promise to multiple requests. It's far simpler and doesn't use a locking construct.
    - inglor 7y ago
      A promise is a lock in that resolving it is the 'release' and awaiting it is `acquire`. For example: ``` let release; const acquire = new Promise(resolve => release = resolve); (async () => { await acquire; // use here release(); // now others can use it })(); ``` This is a bit different because multiple people can await the lock here so it's like a "one time multicast mutex" making it more akin to condition variables. That said - thinking about it as a mutex is a really backwards way in my opinion.
- jnbiche 7y ago
  You write this boilerplate to avoid one extra non-cached HTTP call on a (browser?) client? Am I understanding correctly?
  - deleted 7y ago
    [deleted]
  - matharmin 7y ago
    It's really not a lot of boilerplate - once you have the small utility function, it can be one additional line of code.
  - londons_explore 7y ago
    One extra call could be a multi-megabyte video chunk, or the code flow might mean this case always occurs, potentially hundreds of times before the promise resolves.
- tiglionabbit 7y ago
  Caching the promise is a perfectly good solution. Locks aren't needed.
- random314 7y ago
  When your program is single threaded, a simple boolean flag variable can act as a mutex, you don't need a mutex for this. Mutexes are for situations where flag variables can change state between your instructions to check and set a flag. This can only happen in multithreaded or interrupt driven code.

PetahNZ 7y ago

One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.

kbenson 7y ago
Seems like you should be able to build a lock mechanism fairly simply with async/await, but I agree, it would be nice if it was a built in primitive. It does feel a little silly to implement a lock function when the engine much be using one to support its async functionality in the first place, so you're introducing a lot of inefficiency.
- Arelius 7y ago
  I don't think it's true that the engine must be using a mutex to support it's async functionality. Or that it is true that an OS mutex will be any more efficient than alternative solutions. A mutex really can only exist to serialize async code. If you want it serialized that likely means that code shouldn't be async in the first place.
  - kbenson 7y ago
    You're right that it may not be required for the async functionality (especially since lock-free schedulers exist, and the engine is basically a single processor scheduler for processes). I do think it's likely in use other places though, just because it's much easier to write correct code with one.
- matharmin 7y ago
  Implementing a mutex is very simple and efficient in JavaScript - probably much lower overhead than the Promises itself.
Arelius 7y ago
Do you really want to block all of your http calls on the result of the prior call in the off-chance that they might share a result just so you can only cache the results and not the promises? The reason we don't have a mutex in javascript is that there are better solutions to the problems it solves.
- hombre_fatal 7y ago
  Maybe I don't understand your response, but a map of promises to handle parallel in-flight requests for the same resource (which the grandparent pitched) is basically the most elegant yet simple solution to this common problem. I don't really see how it's a mutex though, you're just returning the same promise to multiple requests. It's far simpler and doesn't use a locking construct.
  - inglor 7y ago
    A promise is a lock in that resolving it is the 'release' and awaiting it is `acquire`. For example: ``` let release; const acquire = new Promise(resolve => release = resolve); (async () => { await acquire; // use here release(); // now others can use it })(); ``` This is a bit different because multiple people can await the lock here so it's like a "one time multicast mutex" making it more akin to condition variables. That said - thinking about it as a mutex is a really backwards way in my opinion.
jnbiche 7y ago
You write this boilerplate to avoid one extra non-cached HTTP call on a (browser?) client? Am I understanding correctly?
- deleted 7y ago
  [deleted]
- matharmin 7y ago
  It's really not a lot of boilerplate - once you have the small utility function, it can be one additional line of code.
- londons_explore 7y ago
  One extra call could be a multi-megabyte video chunk, or the code flow might mean this case always occurs, potentially hundreds of times before the promise resolves.
tiglionabbit 7y ago
Caching the promise is a perfectly good solution. Locks aren't needed.
random314 7y ago
When your program is single threaded, a simple boolean flag variable can act as a mutex, you don't need a mutex for this. Mutexes are for situations where flag variables can change state between your instructions to check and set a flag. This can only happen in multithreaded or interrupt driven code.