Hacker News Reader

Comment by zokier | Hacker News Reader

I haven't yet read the paper proper but this statement surprised me a little:

> In particular, ownership has forced us to avoid concurrency in the kernel and include more code than we would have liked in the TCB.

One of the strong points of Rust and its owenership system is that it allows writing concurrent code with greater confidence. I would have hoped that it'd encourage rather than discourage using concurrency.

View on HN

I was surprised by this as well, so I checked their paper:

"When multiple threads need to share a resource, they can pass ownership through channels. However, as we discuss in the rest of this paper, it does not work well in systems that use non threadbased concurrency models and when resources must be shared [...]

While hardware interrupts are asynchronous, and therefore run concurrently with other kernel code, in our operating system interrupt handlers enqueue tasks to be run in the main scheduler loop, which is single-threaded. As a result, on_receive and send can never run concurrently and no data race is possible. We overcome both issues by declaring most resources as static variables and borrowing them with ’static lifetime. [...]

Being able to mutably borrow static variables multiple times means our operating system can allow multiple drivers to reference hardware resources or each other. However, doing so means we lose the ability to detect real data races at compile time, for example, if the kernel passes a shared resource to an interrupt handler that may run concurrently. Instead, we resort to an overly conservative convention in which interrupt handlers perform no work except posting to the main scheduler’s task queue. An ideal mechanism would, instead, allow for shared state between components that will never run concurrently, but disallow sharing when they may."

Rust's rules here aren't purely for multithreading, though. For example, even in a single-threaded context, disallowing mutable aliasing prevents things like iterator invalidation.

At the same time, I noticed this paper late last night, and just woke up, so haven't fully let it all sink in yet.

> Instead, we resort to an overly conservative convention in which interrupt handlers perform no work except posting to the main scheduler’s task queue

This doesn't seem so bad. OS X does exactly this in order to minimise the time spent in interrupt mode, and so reduce scheduling jitter:

https://developer.apple.com/library/mac/documentation/Darwin...

https://developer.apple.com/library/mac/documentation/Device...

In reality, IOKit drivers do perform work in the interrupt filter function that actually runs in an interrupt context.

I think every OS does this to some extent. Windows uses DPCs, Linux uses tasklets.

Yeah, this seems like the right thing to do in the context of interrupt handlers. You want to get out of them as fast as possible.

To be honest, they don't seem to be very proficient at using Rust properly.

Of course, this means that the documentation or other instruction materials might need to be improved.

It's understandable that they're not proficient in Rust, given how new the language still is. :) In particular they weren't aware of the Cell type in the stdlib which allows zero-cost shared mutability for any type that's copyable, which may have addressed some of their problems. You're right in that this means that we need more teaching materials, which is an active area of effort!

Reply on news.ycombinator.com