If we had an operating system where every system call used an async calling interface, the type of spinlock latency observed in this article would be greatly reduced. It wouldn’t bring Moore’s Law back but it would make the most of what CPU resource we have.

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.

This has nothing to do with Moore's Law or improving processors directly. If anything, this is a software optimization problem. Half of what I mentioned was locks and schedulers, which are directly software problems. Layer on the fact that a helloworld application in most languages and frameworks is 100s of KB to dozens of MBs, and you have really, really, unoptimized software. 30 years ago, lots of software was written in Assembly and some C. But software has gotten fatter and slower at a much much faster rate than hardware has gotten faster/more parallel since the industry introduced ILP, caches, multi-stage instruction pipelines, etc. with the Pentium/5x86 class microcomputers & processors. Most people never learn to write multi-processing, multi-threaded, multi-programming, event-driven, decentralized or distributed applications. The model that browsers and most languages & frameworks provide is usually inherently sequential and single processing.

If web developers never learn to write multi-processing, multi-threaded, multi-programming, event-driven, decentralized or distributed applications the web will forever look like it looks today.

> This has nothing to do with Moore's Law or improving processors directly. If anything, this is a software optimization problem.

This is such a contradictory sentence. The whole point of Moore's law was that software developers could do what they want, freed by limitations of hardware because in 18 months, when their product was ready for launch, the hardware became capable enough to handle it.

Forcing developers to focus more and more on performance (via threading, distributed systems, and custom die co-processors), rather than innovating new applications, is a huge shift. It's like the hardware developers gave up, and tell the software developers that it's in your hands now.

Also, comparing a hello world program 10 years ago to today is a meaningless comparison because no one uses hello world to do anything. A better example would be Excel in 1998 and Excel in 2018. Sure today, it's a 500 megabytes instead of a just a handful, but it does quite a bit more (for better or worse).

You don't understand Moore's Law. Moore's Law says nothing about software devs doing what they want or processor speed or even hardware capabilities or qualities. It's about the manufacturing capability and integration by semiconductor fabs. Specifically, "Moore's law is the observation that the number of transistors in a dense integrated circuit doubles about every two years.' [0]. Hardware engineers never gave up; they're the reason your bloated apps takes 60 secs to startup instead of 3600 secs.

[0] https://en.wikipedia.org/wiki/Moore%27s_law

The internet, sure. But GPUs will figure out new ways to parallelize, which is not dead yet.

The problem is not that we cannot parallelize hardware. The problem is that the software making use of it is lacking. 24 cores is plenty, but if most software only uses one core even more cores won't help.

GPUs can just do fast matrix multiplications in parallel, but it’s up to the developer to reframe their software into matrix multiplications. For some applications it’s great, but for most it isn’t realistic.

Also if General processors are now hitting a wall, it’s only a matter of time before GPUs do.