1134974 - Global futex lock is likely to be contended

Status: RESOLVED DUPLICATE of bug 1268793

(Core :: JavaScript Engine, defect)

Description

[Lars T Hansen [:lth]]

We should not touch this bug until there's evidence of a problem, but the global lock that controls the futex data structures could be a performance bottleneck: suppose two threads are communicating through location L and two others are communicating through location M.  All four will contend for access to the same futex lock, even though the two pairs are independent.

It is probable that we could instead have one lock per location that futexes are waiting on; wait/wake fairness is only per-location, so this should not affect semantics.

If we just blindly allocate one lock per location we wait on then we'll end up in the same lock GC problem we were trying to avoid by going with the futex API in the first place.  So something cleverer is needed.

Comment 1

[Luke Wagner [:luke]]

I'm guessing you intended to block another bug :)

Comment 2

[Lars T Hansen [:lth]]

There's a long discussion about the problem here: https://github.com/tc39/ecmascript_sharedmem/issues/12, where a concurrent hash table (presumably hashing by address of the word) is advocated.

A completely different take on it is a patch on 1248670, which attempts to speed up futexes by emulating some synchronic facility under the hood; that is probably misguided (and it breaks some guarantees) but may still be interesting to consult.