Google Finally Begins Their Open-Source Dance Around Linux User-Space Threading

[phoronix]

Phoronix: Google Finally Begins Their Open-Source Dance Around Linux User-Space Threading

Way back in 2013 there was a presentation at the Linux Plumbers Conference around Google's work on user-level threads and how they were working on new kernel functionality for using regular threads in a cooperative fashion and building various features off that. Fast forward to today, that functionality has been in use internally at Google for a range of services for latency-sensitive services and greater control over user-space scheduling while now finally in 2020 they are working towards open-sourcing that work...

http://www.phoronix.com/scan.php?page=news_item&px=Google-User-Thread-Futex-Swap

[bug77]

I'm really confused about all this newfound interest in cooperative multitasking (coroutines in every language, now this). Windows up to 3.11 was all about cooperative multitasking, am I the only one that remembers how that went?

[ssokolow]

I'm really confused about all this newfound interest in cooperative multitasking (coroutines in every language, now this). Windows up to 3.11 was all about cooperative multitasking, am I the only one that remembers how that went?

Pre-emptive multitasking can't be blocked by a misbehaving participant simply by failing to yield often enough. Cooperative multitasking can be made lighter and more performant. (Which is one reason older OSes for very limited hardware used it.)

Thus, pre-emptive multitasking is good between programs, while cooperative multitasking is good within a program, where the same person is writing all the threads involved and needs to boost performance further.

(More isolation, more resource burden.)

[Guest]

Pre-emptive multitasking can't be blocked by a misbehaving participant simply by failing to yield often enough. Cooperative multitasking can be made lighter and more performant. (Which is one reason older OSes for very limited hardware used it.)

Thus, pre-emptive multitasking is good between programs, while cooperative multitasking is good within a program, where the same person is writing all the threads involved and needs to boost performance further.

(More isolation, more resource burden.)

What kind of applications will benefit this? Examples?

[bug77]

Pre-emptive multitasking can't be blocked by a misbehaving participant simply by failing to yield often enough. Cooperative multitasking can be made lighter and more performant. (Which is one reason older OSes for very limited hardware used it.)

Thus, pre-emptive multitasking is good between programs, while cooperative multitasking is good within a program, where the same person is writing all the threads involved and needs to boost performance further.

(More isolation, more resource burden.)

Obviously removing checks is faster than enforcing them. Doesn't make the practice less dangerous.

Guest Look at Go's goroutines: lightweight threads multiplexed over as many OS threads as you allow on startup. But those come with a dedicated communication mechanism (channels) and a set of practices for how to use them. The practices are not enforced in any way, so you're still given enough rope to hang yourself.

[ssokolow]

Obviously removing checks is faster than enforcing them. Doesn't make the practice less dangerous.

Pre-emptive multitasking vs. cooperative multitasking usually isn't about removing checks, but about having the application cooperate with the scheduler to minimize the amount of state that needs to be saved and restored when switching scheduling quanta.

You can have OS threads within an application deadlock just as easily, but they also have full stacks that have to be saved and restored by the kernel.

[bug77]

Pre-emptive multitasking vs. cooperative multitasking usually isn't about removing checks, but about having the application cooperate with the scheduler to minimize the amount of state that needs to be saved and restored when switching scheduling quanta.

You can have OS threads within an application deadlock just as easily, but they also have full stacks that have to be saved and restored by the kernel.

I was thinking more like, in pre-emptive multitasking the OS checks/schedules when a thread should run and can interrupt misbehaving threads. But I missed that if you do cooperative multitasking at user level, it doesn't matter whether you behave or not, you're still in a pre-empted thread.
The things one realize when they write them down...

And now I realize I need to look into how Rust does async/await, because that thing is only supposed to have OS-level threads built-in.

[indepe]

FUTEX_SWAP seems like a good optimization that's useful in general, not just in the context of cooperative multitasking.

Also good would be the possibility to submit (multiple) FUTEX_WAKE calls with io_uring.

And then to combine the two features such that submitting a FUTEX_SWAP-like call with a wait-for-io_uring option will swap the submitting thread. If you know what I mean.

Another one I can think of is a "I'm waiting for thread tid" call (syscall if not io_uring), that will schedule that thread if it isn't already running, and perhaps even give it a higher priority (think priority counter-inversion).

[pal666]

What kind of applications will benefit this? Examples?

i didn't read subj presentation, but in general there are several ways you could use userspace context switching: you could make lightweight threads, or you could make stackful coroutines. stackful coroutines do not need memory allocation of stackless coroutines, but they need separate stacks. also stackful coroutines are easier to integrate with non-coroutine-aware code and do control inversion. coroutines look more natural than traditional asynchronous code. lightweight threads are coroutines with a scheduler
user-space implementations of
lightweight threads https://www.boost.org/doc/libs/1_73_...tml/index.html
stackful coroutines https://www.boost.org/doc/libs/1_73_...ne2/index.html
(maybe not so)traditional asynchronous code https://www.boost.org/doc/libs/1_73_...sio/index.html
benchmark results against competition https://www.boost.org/doc/libs/1_73_...rformance.html

[pal666]

now i've read presentation, it's actually about kernel-level threads, but with telling scheduler where to switch to instead of hoping that it will reschedule target thread soon enough