1248670 - SAB+Atomics "synchronic" API

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Lars T Hansen [:lth]]

The futex API is very difficult to use correctly and efficiently, there are footguns and performance traps everywhere.  I'm experimenting with a slightly higher-level API based on the C++ "synchronic" proposal, that can complement or perhaps eventually replace the futex API.

Comment 1

[Lars T Hansen [:lth]]

Attachment: WIP

Comment 2

[Lars T Hansen [:lth]]

Attachment: WIP

Comment 3

[Lars T Hansen [:lth]]

Attachment: bug1248670-fast-futex.patch

An alternative idea: speed up futexes using ideas from synchronics.  This code is not quite done.  It makes futexes about 10x faster for a simple ping-pong benchmark, which is still about 4x slower than naively implemented synchronics.  Additionally, attaining that performance required a number of optimizations and the code is fairly complex (and not vetted, and not quite complete).

It's probably the case that for synchronics to scale well some of these ideas are required for synchronics as well, and that may create some constant overhead that slows down simplistic benchmarks, but for now, "fast futexes" are less appealing than going with synchronics.

Comment 4

[Lars T Hansen [:lth]]

A couple of notes about the fast futexes:

- It's no longer possible to tell how many waiters were woken (because they're spinning and we don't want
  to have to account for that) so the "count" argument to futexWake and the return value from ditto
  need different semantics.
- It's no longer possible to guarantee that waiters are woken in order - we don't want a spinning waiter to
  get stuck behind one that has to be woken up, and a waiter can wake up in any case without a futexWake
  call happening.

So these are not really "futexes" in the same sense as before.

Comment 5

[Florian Scholz (Open Web Docs)]

Setting ddn as it helps me to track this. Note that work on dev docs usually only starts once bugs are resolved. Feel free to remove dev-doc-needed if this API remains an experiment (without standardization).

Comment 6

[Lars T Hansen [:lth]]

Proposal retracted.