Wasn't the lock in the article kind of async? From my understanding, the problem was not the wait time on the lock alone, but that the lock is not fair: so even if you asynchrounously locked, someone else (in this case the WMI scan) can get the lock everytime before you get it so you are blocked a long time (you cannot continue with this particular operation until you get the lock, even in the async case).

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.

Don’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.

The 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.

If every OS required async calls, it would require every developer to learn async programming. They probably wouldn't learn it properly, and you'd end up with more race conditions and bugs than if async was optional.

Closures/blocks really make it a lot easier to follow the flow of async coding.

Async style enforces a kind of minimalism that in my opinion simplifies the problem space overall. Obviously, one has to learn different approaches to problem definition and solution to embrace event-driven coding.

To me, in the comparison of linear programming handling an exception when your call stack is 5 levels deep (or maybe 3 in a different use case), having to bubble the appropriate handling at each of those levels, versus async where in your closure you have a 4-line if/else construct that fires off one event for success and a different event for failure, async wins the simplicity competition every time.

If race conditions are an issue, events should be dispatched through a single-threaded finite state machine dispatcher for resolution. Such events can fire up multiple worker threads to do their bidding, but when state changes, that goes through the dispatcher which inherently resolves all races.