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.
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."
> 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:
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.
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!
> 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.