4 ms·
Wow, this feels wrong way to do it. The way i see it, threads and processes waiting on some resource should be able to update some piece if metadata pointing to
by hamilyon2 3y ago
Wow, this feels wrong way to do it. The way i see it, threads and processes waiting on some resource should be able to update some piece if metadata pointing to the thing they are waiting for. This will allow "donating" their priority and cpu share to the other process/thread.
This can be a general mechanism, which can be incorporated in the things kernel already know, creating a chain of dependencies and giving priority to something at the end of chain.
- jorlow 3y agoI think you're describing traditional scheduling. The point is that sometimes overheads from cache thrashing and context switches are worse than just spinning.
- hamilyon2 3y agoMy information about locking and scheduling is dated and naiive. What is preventing per-thread structure of two identifiers "I am waiting for thing X, give it priority" and "I am in posession of X"? Identifiers are random numbers. System call is not necessary, some writable location is enough.
- gpderetta 3y ago> threads and processes waiting on some resource should be able to update some piece if metadata pointing to the thing they are waiting for This will allow "donating" their priority and cpu share to the other process/thread. That's what, for example, futexes are for. But the "donating" part can be expensive, so short spins can actually be beneficial for overall system efficiency.