User-managed concurrency groups

Posted Dec 28, 2021 17:11 UTC (Tue) by khim (subscriber, #9252)
In reply to: User-managed concurrency groups by ms
Parent article: User-managed concurrency groups

> I've sometimes read one of the reasons green threads have fast context switching is because the kernel isn't involved.

Switching to kernel and back is not that slow (even green threads do syscalls). What's slow is waiting for next thread to be scheduled by kernel to become executable.

> My question is how can it help, getting the kernel involved?

Basically a band-aid for the fact that many years ago GNU/Linux rejected NGPT and went with NPTL.

If you allocate, essentially, a dedicated kernel thread for your “green thread” then you may use all syscalls and libraries which are allowed for regular threads: parts of the program where “green threads” are cooperating would work like proper “green threads”, but if you call some “heavy” function the instead of freezing your whole “green thread” machinery you would just get one-time hit when kernel would save your beacon and would give you a chance to remove misbehaving “green thread” from the cooperating pool.

> About the only reason I can think of is you'd gain pre-emptive eviction, which is not nothing, but I'm curious if it's worth it, or if there are other benefits too?

Proper TLS area is another benefit. In systems where (like in Windows) fibers (AKA “green threads”) their own private storage but share TLS for “kernel threads” it's much easier to mess things up.

Of course that one is possible without kernel help, but you get it for free if you use kernel thread machinery as “safety net” for misbehaving fibers.