kubanrob
commented
4 years ago Our test application has some loops that busy wait on a shared variable, which obviously deadlocks when the writer is waiting on the same hardware thread and never gets a chance.
This concern will eventually lead to some sort of "fair" scheduler. Do we want/need this?
Imagine a situations with multiple busy waiting threads and one that could make progress. If we do not have a good idea who should be next, a naive implementation of the above idea might just switch between the waiting threads.
FIFO semantic for the ready list is probably enough? Or we could drop yielding threads in priority, but introducing priorities opens another can of worms.
I guess what I trying to say is: Before we implement something like this, we should think about the guaranties the scheduler should/can provide.
Can be similar to the poll systemcall, but also makes sure to switch to the next EC in the scheduler's ready list.
This is needed for cooperative multi-tasking when multiple Execution Contexts share the same hardware thread. Our test application has some loops that busy wait on a shared variable, which obviously deadlocks when the writer is waiting on the same hardware thread and never gets a chance. Same is true for the simple user-space mutex implementation. Likewise, OpenMP has the option to yield in order to implement oversubscription without too much performance penalty. Maybe not everything is done through the futex mechanism...