3 ms·

Right, but the point is that to date, being careless about asking for an atomic type explicitly would not lead to buggy behavior. But now it will, so some folks

by drfuchs 10y ago

Right, but the point is that to date, being careless about asking for an atomic type explicitly would not lead to buggy behavior. But now it will, so some folks are going to be stumped when they use their old habits and get flakey results. Not that there's anything to be done, other than warning folks that they can't just widen their integer types and expect it to work without checking for this case.

steveklabnik 10y ago
In Rust, you don't get buggy behavior in this kind of case: your program fails to compile.
Tuna-Fish 10y ago
The situation where the atomicity of integer operations matter is when there are multiple references to a single memory location, at least one of which is mutable. The entire basis of the memory protection model of Rust is that it makes the above impossible in safe code. If you attempt to create such a situation, the compiler will fail to compile your code. Every single integer operation could stop being atomic and not a single line of safe rust would break.
cesarb 10y ago
> Right, but the point is that to date, being careless about asking for an atomic type explicitly would not lead to buggy behavior. That's already the case: simply reading a 64-bit integer in a 32-bit processor is not atomic, and that's already possible today. But that's not a problem in Rust. How would you access the same 128-bit integer from more than one thread? - You pass the thread a copy of the value: the thread's copy can't be accessed by any other thread, so whether or not it's atomic doesn't matter. - You pass the thread a mutable reference (&mut) to the value: one of Rust's rules is that there can be only one &mut to a memory location, and while that &mut exists, nothing else can read or modify the value. Therefore it's the same case: only one thread can access the value, so whether or not it's atomic doesn't matter. - You pass the thread a non-mutable reference (&) to the value: another of Rust's rules is that while any non-mutable reference exists, nothing can modify the value, so the reads not being atomic don't matter. - You wrap the value in something like a Mutex: the Mutex has a lock which prevents concurrent accesses in the middle of a write. - You use an Atomic version of the 128-bit integer: this one doesn't exist, so can't be used. The main reason for all the interest in Rust is that the compiler protects you from many kinds of mistakes. Accessing the same variable from more than one thread, without using a lock or an atomic, is one of the things the compiler protects you from.

by drfuchs 10y ago

steveklabnik 10y ago

In Rust, you don't get buggy behavior in this kind of case: your program fails to compile.

Tuna-Fish 10y ago

The situation where the atomicity of integer operations matter is when there are multiple references to a single memory location, at least one of which is mutable. The entire basis of the memory protection model of Rust is that it makes the above impossible in safe code. If you attempt to create such a situation, the compiler will fail to compile your code. Every single integer operation could stop being atomic and not a single line of safe rust would break.

cesarb 10y ago

> Right, but the point is that to date, being careless about asking for an atomic type explicitly would not lead to buggy behavior. That's already the case: simply reading a 64-bit integer in a 32-bit processor is not atomic, and that's already possible today. But that's not a problem in Rust. How would you access the same 128-bit integer from more than one thread? - You pass the thread a copy of the value: the thread's copy can't be accessed by any other thread, so whether or not it's atomic doesn't matter. - You pass the thread a mutable reference (&mut) to the value: one of Rust's rules is that there can be only one &mut to a memory location, and while that &mut exists, nothing else can read or modify the value. Therefore it's the same case: only one thread can access the value, so whether or not it's atomic doesn't matter. - You pass the thread a non-mutable reference (&) to the value: another of Rust's rules is that while any non-mutable reference exists, nothing can modify the value, so the reads not being atomic don't matter. - You wrap the value in something like a Mutex: the Mutex has a lock which prevents concurrent accesses in the middle of a write. - You use an Atomic version of the 128-bit integer: this one doesn't exist, so can't be used. The main reason for all the interest in Rust is that the compiler protects you from many kinds of mistakes. Accessing the same variable from more than one thread, without using a lock or an atomic, is one of the things the compiler protects you from.