Hacker News Reader

Comment by klickverbot | Hacker News Reader

Given that about every other line in the example stack implementation is marked as "unsafe", I fail to see how Rust is any more safe or well-suited for this than other low-level programming languages (C++, D, etc.).

View on HN

As others have said, in a low-level setting like this it would be very difficult to ensure total safety, which depends on complex data structure invariants.

That said, Rust is able to eliminate some sources of unsafety here -- in particular, it guarantees that you have pinned to an epoch before you get your hands on any snapshots, and provides statically safe access to the snapshots for as long as you're pinned. This is very similar to the way that Rust deals with locks, which is explained more in an earlier post: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

I see 3 lines/expressions marked `unsafe` in http://aturon.github.io/blog/2015/08/27/epoch/#treiber%27s-s... and a tweaked `unlinked` API could cut that down to 2, and removing the unsafety from `cas_shared` (which doesn't strictly need it, but is a major contributor to any issues that could occur) would cut it to 1. Those lines are exactly the danger-points of the data structure, i.e. where misuse can cause use-after-free.

In any case, Rust really shines for the Owned and Shared types, where the affine typing & lifetimes allows sharing to be controlled so that most operations are perfectly (memory-)safe, with compile-time guarantees.

The number of individual lines marked "unsafe" isn't what's important. The safety of those lines relies on invariants put in play by by the rest of the code. All the code behind an asserted-to-be-safe API has to be correct, or incorrect but lucky, in order for the data structure to be safe.

And yet Rust still provides tremendously more type safety in this application thanks to the lifetime system statically verifying the accessibility of the guarded data. It's true that unsafety is a stateful property than a local one, but unsafety still has to involve the unsafe block somehow and that's enormously useful for auditing, debugging, and providing general assurance towards code correctness.

Oh, it's also worth saying that only the `unlinked` method really has to be unsafe, since it's the root of any unsafety with this API. I chose to make the `_shared` methods unsafe as well because they present one of the ways that using `unlinked` could go wrong, but you could reduce the amount of unsafety to a single line in principle.

After discussing idioms with a few others on the Rust team, I've pushed this refactoring, bringing the example down to a single use of `unsafe`. Feels much cleaner, and draws attention to `unlinked` as the source of unsafety here.

Here is the commit for the benefit of others: https://github.com/aturon/crossbeam/commit/cc57af9e63a04013f...

The important thing is that the unsafe implementation satisfies the invariants of type system. So the unsafety is contained within a much smaller surface area than those other systems programming languages.

The presence of “unsafe” doesn’t make Rust unsafe. It’s memory-safe by default—you just use “unsafe” to assert to the type system that you have personally verified the invariants that the type system can’t verify. And if it turns out you were wrong and get a segfault or what have you, you can grep the code for those bits you need to verify. The enemy, as they say, is Murphy, not Machiavelli.

I believe that you've overlooked the section entitled "The Rust API", which goes into detail about how it uses lifetimes and the borrow checker to help ensure correct usage of the API. It's a shame that the API can't be 100% safe, but let's not pretend there's no merit to it.

Besides the fact that there isn't that much unsafe code in there as you say, Rust is more safe because the unsafety is confined to some of the implementation. Now, this library can be safely used with all kinds of pointer gymnastics without any worries.

Reply on news.ycombinator.com