Threads and fibers

[AndrewAPrice]

I was thinking about scheduling, and how it would be useful to have both threads and fibers. The idea I'm toying with is:

Threads are preemptively multitasked, and fibers are cooperatively multitasked (within the same process.)

Threads (within the same process) get scheduled in a round robin fashion, while there will only be one awake fiber per process per core. The other fibers will be "pending" (awake but won't get scheduled) unless there are no other fibers currently running in that core for that process.

Anything code that runs in a fiber could run in a thread, but I thought there could be performance advantages if you kicked off task-sized bites that would not get interrupted by another fiber unless explicitly giving up control (by terminating, or sleeping because we're waiting on IO or a mutex.) If your process wanted to do something CPU intensive, you'd explicitly create a thread instead of a fiber.

Or, we could just implement fibers in userland?

Has anyone implemented fibers in their kernel?

I'm also imagining a situation where if there is only one awake process with one awake thread or fiber, we could switch off the timer interrupt, giving the task at hand a little more CPU time. (Maybe this is risky.)

[OSwhatever]

Threads and fibers and not mutually exclusive and there are several implementation today of fibers in various libraries. The D language implements fibers in their standard library and is entirely a user space creation. What is needed is some kind user space task switcher which of course will be architecture dependent. Fibers exist in other languages as well.

My OS has kernel threads and user space threads, these two are completely disjoint. One drawback with user threads is that preemption between threads in the same process becomes more difficult so time slicing is not that simple. It isn't impossible though but requires more complexity. Still yielding a user space thread is simple. My OS does not have user thread time slicing and I haven't so far seen any use for it and the system is built on short lived user space threads.

If you are interested in this subject first place to read is Scheduler Activations:
https://en.wikipedia.org/wiki/Scheduler_activations
https://web.eecs.umich.edu/~mosharaf/Re ... ations.pdf

Also interesting is MS user mode scheduling, dive further in there in order to see how they have solved it.
https://docs.microsoft.com/en-us/window ... scheduling


There is one misconception about user mode scheduling that it is faster than a kernel thread only system, this is not the case and user mode scheduling does not really reduce the number of kernel API calls that it matters. This is one of the reasons the scheduler activation solution was not becoming popular in Free BSD.

[AndrewAPrice]

Thank you for the links! This is kind of what I set out to do, but with more control (e.g. you can have multiple N:M threads.) My model doesn't have that level of control, but instead treats the scheduler as a thread pool, with the fibers being tasks than can be interrupted and resumed when blocked (such as on IO or a mutex).