Examples for Sync/Send leave too many open questions
proski opened this issue · comments
Problematic page:
https://google.github.io/comprehensive-rust/concurrency/send-sync/examples.html
Example of inaccuracy:
Arc<T> is in the Send + Sync section. However, a later page about Arc says that it's not true for all types:
It implements Send and Sync if and only if T implements them both.
What is T anyway? Shouldn't trait bounds be included?
Clarification needed:
Both bool and AtomicBool are in the Send + Sync section. What's the point in having AtomicBool?
i8 and AtomicU8 are in the Send + Sync section. No mention of u8 or AtomicI8 (which exists). It might give a wrong impression that i8 and u8 have some differences w.r.t. synchronization.
Possibly extraneous:
These types are thread-safe, but they cannot be moved to another thread:
- MutexGuard<T: Sync>: Uses OS level primitives which must be deallocated on the thread which created them.
It feels like a zoo with exotic animals. I'd rather see an exact definition of "thread-safe".
Hi @proski!
Possibly extraneous:
These types are thread-safe, but they cannot be moved to another thread:
- MutexGuard<T: Sync>: Uses OS level primitives which must be deallocated on the thread which created them.
It feels like a zoo with exotic animals. I'd rather see an exact definition of "thread-safe".
Yeah, this slide is tough... I normally have to add a lot of context around it when teaching. So we should start by adding the missing information to the notes at the bottom of the page.
If you like, you could send us a PR with any information you've found useful yourself.
These types are thread-safe, but they cannot be moved to another thread:
- MutexGuard<T: Sync>: Uses OS level primitives which must be deallocated on the thread which created them.
It feels like a zoo with exotic animals. I'd rather see an exact definition of "thread-safe".
I would say that in this context "thread-safe" is trying to convey that these are types whose values can be safely accessed from multiple threads concurrently. This means, of course, having a reference to them in multiple threads, AKA Sync. This makes sense for MutexGuard, as its most useful attribute is its Deref::deref method which takes &self.
It would be good to clarify this in the slide content itself.