Normative: Remove line-cutting semantics for Atomics.wait

[syg]

The line-cutting semantics was originally motivated by the anomaly that resolving Atomics.waitAsync Promises does no meaningful work if the agent is blocked by an Atomics.wait.

However, it's hard to reason about line-cutting semantics because it undermines the currently simple FIFO fairness model, and it also doesn't actually solve the problem. The core ergonomics problem is the futility of resolving Atomics.waitAsync Promises while the agent is blocked -- regardless of location. The Atomics.wait/wake semantics, however, is staunchly per-location. Solving the very narrow blocked agent problem for a particular location is not worth the complexity.

Since this is a change to core semantics, please re-review @kmiller68 @littledan @ljharb

[syg]

Also @lars-t-hansen.

[lars-t-hansen]

I agree. ISTR the original semantics were conceived as a workaround in a simple two-agent single-location setting, but make less/no sense for multi-agent and, as you say, multi-location settings. Indeed, given agents A B C and location L, it is possible for A to asyncWait on L, and for B to attempt to notify A on L, but for C to intercept that notification by issuing a blocking wait on L - C will be given priority. (Possibly this is what you say when you say it's hard to reason about the line-cutting.) In this case, with A not being blocked, A really should be given the goahead before C.

The situation of A doing asyncWait and then wait will have to fall into the category of "don't do that, then".

[lars-t-hansen]

I can't imagine any problems that this approach would cause.

Well, deadlocks ;-)

Seriously, I think the original semantics went too far in the direction of coddling the programmer. Right now I can't remember if they were the result of a discussion or something I realized while I was designing the feature. But I think cleaning this up is the right thing.

[littledan]

Do we think that this PR will cause deadlocks? I don't really understand the scenario.

[lars-t-hansen]

The wink was intended to signal that it was a joke. I don't think there's any added risk of deadlocks after making this change.

[syg]

Right, there is no danger of deadlocks here.

On Tue, Nov 26, 2019 at 4:11 AM Lars T Hansen notifications@github.com wrote:

The wink was intended to signal that it was a joke. I don't think there's any added risk of deadlocks after making this change.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-atomics-wait-async/pull/20?email_source=notifications&email_token=AAAXLUNHMHOTTVJD2KTN2DTQVUHALA5CNFSM4JRRLV72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFFZKHQ#issuecomment-558601502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAXLUJEL2JBWU6J5F5HVYDQVUHALANCNFSM4JRRLV7Q .