Hacker News Reader

Comment by amelius | Hacker News Reader

An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model.

What's old is new again ...

Well, there's a big difference:

> Using async/wait, we now have basic support for cooperative multitasking in our kernel. While cooperative multitasking is very efficient, it leads to latency problems when individual tasks keep running for too long and thus prevent other tasks to run. For this reason, it makes sense to also add support for preemptive multitasking to our kernel.

> In the next post, we will introduce threads as the most common form of preemptive multitasking. In addition to resolving the problem of long running tasks, threads will also prepare us for utilizing multiple CPU cores and running untrusted user programs in the future.

It seems the plan here is to use this for internal work, and still give a preemptive multitasking API to userspace.

Isn't that driving against the lesson learned from the past though? 3rd party drivers can not be trusted to behave and hang the kernel when doing so with cooperative multitasking.

I am not sure what Phil's overall kernel design is; you're assuming a monolithic kernel, but not every kernel has drivers in kernel space.

Fair point, looking forward to following along :)

Phil's series is meant for learning rather than production use. So sometimes he takes a "shortcut" in one post then removes the restrictions or workarounds later.

Toy OS, so he has less to worry about. But also maybe just be more careful around kernel modules, if that eventually exists?

GP is not wrong, then: with this implementation, async/await still amounts to the good old cooperative multitasking and does not (yet?) take advantage of threads. (In C#, for example, async/await is indeed different from this, being based on TAP - Task-based Asynchronous Pattern, where tasks are executed "asynchronously on a thread pool thread rather than synchronously on the main application thread.")

Async/await lets you build tasks, but is completely orthogonal to threads. You could set up tasks with a 1:1 or N:M or even single threaded model.

And yes, the GP is not wrong that if this were the only mechanism provided, it would be similar. It does not seem like the plan is to expose this externally whatsoever, though.

Didn't most old operating systems use cooperative multitasking? I remember, at least, that classic Mac OS (i.e. pre-OSX) didn't use preemptive multitasking, either.

Anyway, this SO answer[0] explains why early Linux, much like the hobby kernel in this article, used cooperative scheduling inside the kernel, and only preempted user-space stuff.

[0]: https://stackoverflow.com/a/16766562

MacOS may have been a little late. Windows NT, OS/2, Linux did preemptive multitasking since beginning of 90s, even AmigaOS had it in the 80s.

Mac OS badly needed preemptive multitasking (and memory protection!), and got it when the NeXT bits were transformed into Mac OS X.

Thanks for the link!

I don't understand why this would be different for a Rust based OS..

There is one significant difference: Windows did context-switches in the blocking calls and did not rely on the program code having "the right structure" needed for straight co-routines to work.

The difference between preemptive and cooperative multitasking is not whether you do full context switches, but whether there is a way to do context switch at a point where the process does not expect it (ie. by handling some kind of timer interrupt as scheduling opportunity).

Does Rust allow a computational for-loop to be interrupted somehow?

Computation can also be viewed as a blocking operation.

The only yield points are .await points. If there's an .await in a loop, then sure, but otherwise no.

What is the cost of an .await point?

For this to work, perhaps Rust should cooperate too, inserting .await points at strategic places in the code, to keep cost low but still guaranteeing a certain responsiveness of the overall system.

That would explode the state machine size and make its performance characterization very hard.

And you would need to avoid having any kind of call to external code (or yield before and after every such call, and pray for the best).

If I understand the futures::pending!() macro correctly, one can use that to add a forced yield point in a loop, right?

Yes, it creates a future, and then immediately .awaits it.

That is interesting point that I originally wanted to mention. There are systems that take the middle ground approach of using something that the program has to eventually execute if it is running indefinitely as scheduling opportunity. Typically an backward jump or something that allows you to do backward jump (ie. function call), this is the case for erlang, SOAR (which was recently mentioned on HN) and interestingly enough Ericsson AXE, which is to large extent erlang-like VM implemented in hardware (which predates erlang).

Well, I'm not well versed in the details, but I do wonder if cooperative multitasking isn't a better idea nowadays in the age of ubiquitous multicore.

As Steve’s sibling comment points out, this is only for the kernel. The article mentions preemptive threading for the user space as still being desirable.

I'm not convinced that's actually true though, is what I mean. The big drawback of cooperative is just that a single process can monopolize resources, which in the singlecore days mean the system became unresponsive and you had no way to recover from it. That isn't really true now with multicore. As long as the OS has a core to work on it can terminate or otherwise deal with misbehaving processes.

Again, this is based on my admittedly limited understanding, but I haven't yet seen good reasoning why pre-emptive is still preferred.

> Error: you cannot open another Chrome tab because all your cores are already used up by Slack and VSCode

You would probably still want to preempt, because you're not going to rewrite all the widely used software to actually yield.

Because that's the thing about cooperative multithreading, the participating parties need to cooperate.

And if you look at the amount of threads that some software open it's just crazy. Looking on my machine the top5 are:

1. 260 threads System (ok, that's basically the OS that could be changed).

2. 145 threads Dropbox.exe (that's enough to lock all cores on any single consumer CPU).

3. 87 threads SearchIndexer.exe (also OS, could be rectified).

4. 74 threads EpicGamesLauncher (looks like an i9 is no longer enough)

5. 70 threads MemoryCompression (also OS)

I know not all of those threads are active at all time an I guess all the blocking threads could be said to be cooperating but even Dropbox alone regularly has 3-5 threads running.

There's still so many 2 and 4 core consumer machines out there that cooperative multi-tasking with the current software ecosystem would be a disaster.

Not only would applications keep each other from making regular steady progress but even single applications would regularly hang themselves from all the threads they themselves created if there was no pre-emptive yielding beyond using any OS-call as a yield-point

And what are those threads doing all the time?

On N-core, 2-way SMT hardware (which describes pretty much all consumer hardware), the maximum amount of threads that can be usefully doing work in parallel is between N and 2 * N. Any more threads than that, and it must be the case that you expect those threads to spend a lot of time doing nothing to justify the cost of their creation.

There's two main categories that can justify that. The first is threads that are spending a lot of time stuck in blocking I/O--i.e., they're calling things that exist as yield-points in practical kernels anyways. The second thing is some sort of event processing loop, which looks like kind of like this:

  while (!shutdown) {
    event_t *e = get_next_event(queue);
    if (!e) { sleep_until_work(queue); }
    else { execute(e); }
  }

The call in sleep_until_work already today uses a syscall to indicate that the thread shouldn't be scheduled. But even get_next_event can likely be trivially modified to use a syscall to add an event loop. Since multiple threads are able to enqueue events (else who would fill in work while you're sleeping?), you need some sort of threading library support to implement get_next_event correctly. Change the equivalent of pthread_condvar_wait for your OS to introduce a yield point, and you'll have introduced yield points to the vast majority of applications.

most programs hopefully do the sensible thing. But just having the possibility of one browser tab to spawn 8 web-workers that don't do any IO but just busy-wait makes it clear that current implementations of common software don't play well with that model.

It might not lock-up your OS but it would lock up all of the userland and the kernel couldn't do anything about it, because it can't pre-empt. All it could do under that model is let the user kill the browser or just kill the browser itself automatically.

I think most people would prefer being able to use their PC for other things while transcoding a video or compiling a program at near the PCs full capability. Instead of sacrificing a whole core to the OS and then also having to wait longer for those tasks to finish, plus not being able to do anything else.

A model with less pre-emption is certainly possible, but current end-user software makes an approach without any pre-emption very in-advisable.

That does not follow. Long-running CPU-only tasks are a thing and they may not be aware of each other.

With cooperative multitasking, launching something like a parallel compilation would make your machine unusable.

It is true that it's possible to screw your machine your over in that manner. I was pointing out that the large number of threads wasn't evidence in support of that fact, but rather the contrary; the threads have to already be using existing facilities that provide cooperative sleeping points.

The intention of the author's OS is to use cooperation in kernel space and preemption in user space so your entire comment makes absolutely no sense.

But it was a reply to someone suggesting to use cooperative multitasking for scheduling userspace processes. It does not apply to the article but it does apply to the comment it is replying to.

My understanding is that you've now moved the monopolized case from 1 to N, where N is the number of cores. N is usually pretty small.

The laptop I'm writing this on has four cores, and the Chrome instance has 17 threads running...

Just because a kernel is using something internally doesn't mean it is exposing it to user space applications.

Or MacOS up to and including OS9

Reply on news.ycombinator.com