Restartable sequences

Posted Jul 13, 2015 7:43 UTC (Mon) by HIGHGuY (subscriber, #62277)
Parent article: Restartable sequences

I've always considered that (concurrency-wise) thread-local storage is to userspace threads what per-cpu data is to kernel threads.

Under the assumption that the scheduler always tries hard to keep threads on the same CPU as long as possible, the effect is almost the same. In the best case (N threads <= N CPUs) per-thread ~ per-cpu, in the worst case there can be some bouncing.
But on the other hand side, in this last case you still need locks, atomics or barriers for the per-cpu data case as well, since multiple threads will share the per-cpu data.

On many occasions I believed that per-cpu data in userspace would be great, but every time I concluded that I could reach the same goal with TLS. But, then they're writing an allocator and storing data per-thread is a waste of memory...

Would a vDSO approach with seqlock + CPUID work?
The kernel could increase a sequence number and update current CPUID for every migration (and/or context switch!). Userspace could use the sequence number like a seqlock.