Thread Locals (was Re: State of Loom)

[Andrew Haley]

On 28/05/2020 12:58, Alan Bateman wrote:
> I read the mails from Douglas as a plea for something to help creating a
> cache of mutable objects where it's critical to avoid contention. I read
> it that TLs are being used today as an approximation for CPU locals
> because there isn't anything better. This was the purposes of the
> processorid branch. It has a prototype that exposes a primitive to
> obtain the current CPU ID. It based on the Linux restartable sequences
> mechanism. There's a PoC of LongAdder in that branch but a lot more work
> is needed to see how it might be used in other advanced contexts.  So
> "approximation for CPU locals" is another set of cases that need
> attention, it's just hasn't been high priority of late.

For anyone else mystified by this:

So I was mystified by how getting the current processor ID could help,
and I see it's not just that: there's also a local CAS which only
succeeds if the cpu ID hasn't changed since getProcessorId().  This
allows a thread to do a lock() on a CPU-local lock without needing any
heavyweight memory fence operations or even (usually) incurring any
contention. If a thread is unfortunate enough to be pre-empted while
holding the lock, all that happens is a little contention when another
thread is migrated to the same CPU and tries to acquire the same
resource. If it's essential that the other thread makes forward
progress it could allocate a new Thingy instance rather than waiting.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671