5 ms·
A lot of the issues surrounding M:N threads are a result of poor operating system support. The central problem is that a syscall blocks a kernel thread even whe
by dschatz 13y ago
A lot of the issues surrounding M:N threads are a result of poor operating system support. The central problem is that a syscall blocks a kernel thread even when there are more user level threads to run.
If operating systems supported something like scheduler activations (a 20 year old technique), then this becomes less of a problem. The gist of it is that every time the kernel thread would block, or gets scheduled, instead of returning back to where it was executing, it upcalls into a user level scheduler which can then choose to schedule user threads. Its a shame that this technique isn't more common.
- qznc 13y agoWhy is syscall blocking the central problem? More precisely, what kind of problem is it?
- dschatz 13y agoBecause if I use M:N threading then logically one of my user threads blocked and a different one should run during my timeslice. The kernel however is unaware of how I use the kernel thread and will block, believing that I cannot proceed. 1:1 threading lacks this problem but operations such as creating threads or deleting them require syscalls and are therefore relatively expensive.
- pron 13y agoRight. See the links I posted to Google's proposed Linux kernel changes. I can't wait to use that in Quasar.