Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Rust for an Undergraduate OS Course

rust-class.org

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Using Rust for an Undergraduate OS Course

#11

Post by lucian1900 »

johnhamlet wrote: post #5
dbaupp wrote: post #4

Earlier quoted context omitted.

The "default" communication primitive is message passing; and Rust has linear types, so passing anything from one task to another will disallow the use of that thing in the first task. e.g. let value = something(); channel.send(value); // I can no longer use `value` here, it was moved into the .send call (There is some subtlety here; some values don't move when passed around by value, like primitive numeric types, bu…

Two tasks A and B both send a message to task C. Does the message from A or the message from B get received by task C first? That's a race condition. "A race condition or race hazard is the behavior of an electronic or software system where the output is dependent on the sequence or timing of other uncontrollable events." "It becomes a bug when events do not happen in the order the programmer intended." http://en.wik…

I believe the correct term would be "data race", which is a subset of race conditions. If you have no unsafe blocks, it's impossible to race on memory.

Races related to messages are of course possible.

Re: Using Rust for an Undergraduate OS Course

#12

Post by dbaupp »

johnhamlet wrote: post #7
pcwalton wrote: post #3

Earlier quoted context omitted.

Usually we say data races to be clear. Rust has full support for shared memory, but the compiler ensures that you are not accessing it without locking if it's mutable. (If the memory is immutable you can access it without a lock.) You can of course have races in message passing, or the disk, or the network, etc.

...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control. Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.

No compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.

Re: Using Rust for an Undergraduate OS Course

#13

Post by pcwalton »

johnhamlet wrote: post #7
pcwalton wrote: post #3

Earlier quoted context omitted.

Usually we say data races to be clear. Rust has full support for shared memory, but the compiler ensures that you are not accessing it without locking if it's mutable. (If the memory is immutable you can access it without a lock.) You can of course have races in message passing, or the disk, or the network, etc.

...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control. Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.

I'm defining "data race" in the same way that race detectors do—concurrent access to a piece of memory without use of a synchronization primitive. Rust rules those out at compile time.

Re: Using Rust for an Undergraduate OS Course

#15

Post by johnhamlet »

dbaupp wrote: post #12
johnhamlet wrote: post #7

Earlier quoted context omitted.

...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control. Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.

No compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.

You: "not every non-deterministic piece of code is a race-condition"

Wikipedia: "A race condition ... is ... where the output is dependent on the sequence or timing..."

Boom! Headshot!

Re: Using Rust for an Undergraduate OS Course

#16

Post by johnhamlet »

steveklabnik wrote: post #10
johnhamlet wrote: post #5

Earlier quoted context omitted.

Two tasks A and B both send a message to task C. Does the message from A or the message from B get received by task C first? That's a race condition. "A race condition or race hazard is the behavior of an electronic or software system where the output is dependent on the sequence or timing of other uncontrollable events." "It becomes a bug when events do not happen in the order the programmer intended." http://en.wik…

From your link: C++11 introduced formal support for multithreading, and defined a data race strictly as a race condition between non-atomic variables. While race conditions in general will continue to exist, a "data race" must be avoided by the programmer, who must assure that only one thread at a time may access any variable if the access is for writing.

What does C++11's definitions have to do with anything? This is Rust.

Re: Using Rust for an Undergraduate OS Course

#17

Post by dbaupp »

johnhamlet wrote: post #15
dbaupp wrote: post #12

Earlier quoted context omitted.

No compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.

You: "not every non-deterministic piece of code is a race-condition" Wikipedia: "A race condition ... is ... where the output is dependent on the sequence or timing..." Boom! Headshot!

Being nondeterministic doesn't necessarily meant the output differs. (E.g. a program that increments a global counter (with a lock) once from each of ten threads and prints the count after all threads are finished; the increments happen in a nondeterministic order but the output is always 10.)

Re: Using Rust for an Undergraduate OS Course

#18

Post by 2pxl »

"I'm not aware of any other language that has concurrency constructs as elegant and easy to use as Rust's spawn, and I don't know of any language that comes close to the race-free safety guarantees provided by Rust."

I'd recommend having a look at Erlang, it allows you to start lightweight pseudo processes for concurrency and provides a robust data sharing model.

Not so sure about low level access, we used C for those parts in the OS course I took.

Re: Using Rust for an Undergraduate OS Course

#19

Post by lifthrasiir »

ijl wrote: post #14

Can anyone elaborate on how "Rust changes the way you think"?

With Rust you need to be explicit about everything's lifetime. You cannot allocate some chunk of memory and freely borrow it; when borrowing you need a certificate (i.e. compiler check) that the borrowed reference has a shorter lifetime than that of the referenced memory. It is tremendously different from the absence of such guarantees (like C) or the GC-based weak guarantees (like Java and Go, which does not solve the logical memory leaks anyway [1]).

[1] Not that Rust completely solves the logical memory leaks, but it makes the leaks explicit.

Re: Using Rust for an Undergraduate OS Course

#20

Post by zhemao »

rdtsc wrote: post #6

> Go. Go is a systems programming language Not those kinds of "systems". It is funny, it seems initially it was meant to be those kind of "systems", and then it pivoted as we like to say, to become a "distributed-server-network-backend systems" not "hardware-kernel-OS" kind of systems. And then creators kinds of winged it and remarked how "well, that's what we meant when we said systems". As for Rust, yeah, there are…

I think that is the definition of "systems" the class is using though. If you look at the programming assignments, they are all about implementing programs in userspace and not hacking on the kernel.

Yeah, I was confused at first too. Not sure how you can call it an "OS class" if students never touch kernel code. Although, apparently one project group did manage to write a kernel in rust based off of rustboot (https://github.com/wbthomason/ironkernel).

Post reply on HN