3 ms·
In the article, they illustrate a poor design choice. Or probably more likely, a continuation of the programming practice utilized elsewhere in the kernel. That
by CodeWriter23 8y ago
In the article, they illustrate a poor design choice. Or probably more likely, a continuation of the programming practice utilized elsewhere in the kernel. That being, slap a lock on any resource contention. That practice is necessitated solely by the need to support a linear calling interface. Even if this particular issue were to be fixed through queuing instead of locking, the existence of locks elsewhere will still become an issue in a given use case.
My point is, by design, an operating system that has a fully async interface can dispense with locks altogether. Resource contention is then properly resolved through queuing. The OS can then strictly enforce a priority scheme on its various queues, preventing an opportunistic thread from dominating the system. Or enabling higher priority requests to be serviced first. But that decision is made intelligently, not as a result of optimizing to minimize context switching.
- speedplane 8y agoDon’t see the fundamental difference between locks and queues. In a system that uses locks, the kernel can still internally use queues to grant some lock requests before others.
- CodeWriter23 8y agoThe fundamental difference is this. With locking, when a thread’s time slice expires while holding a lock, the dispatcher switches to a different thread and no other thread can gain that particular lock until the dispatcher resumes the thread holding the lock. No locks means this can never happen.