You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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.
Problematic page:
https://google.github.io/comprehensive-rust/concurrency/send-sync/examples.html
Example of inaccuracy:
Arc<T>
is in theSend + Sync
section. However, a later page aboutArc
says that it's not true for all types:What is
T
anyway? Shouldn't trait bounds be included?Clarification needed:
Both
bool
andAtomicBool
are in theSend + Sync
section. What's the point in havingAtomicBool
?i8
andAtomicU8
are in theSend + Sync
section. No mention ofu8
orAtomicI8
(which exists). It might give a wrong impression thati8
andu8
have some differences w.r.t. synchronization.Possibly extraneous:
It feels like a zoo with exotic animals. I'd rather see an exact definition of "thread-safe".
The text was updated successfully, but these errors were encountered: