Addressing reviewer comments and adding relevant updates

Author: borsakv

src/concurrency.md

@@ -14,8 +14,9 @@ The [`Send`] and [`Sync`] traits are `unsafe` [auto traits] used by the Rust typ
 
 These traits are [marker traits] with no methods. Implementing them asserts that a type has the intrinsic properties required for safe concurrent use. The compiler automatically implements these traits for most types when possible, but they can also be implemented manually. Because other unsafe code may rely on these traits being correctly implemented, providing an incorrect manual implementation can cause [undefined behavior].
 
-r[concurrency.send-and-sync.]
-Some types, such as [`Rc`], [`UnsafeCell`], [`Cell`], and [`RefCell`], intentionally do not implement [`Send`] or [`Sync`]. These types enable unsynchronized shared mutable state, which would be `unsafe` to transfer or share across threads.
+r[concurrency.send-and-sync.non-implementors]
+Some types, such as [`Rc`], [`UnsafeCell`], [`Cell`], and [`RefCell`], intentionally do not implement [`Send`] or [`Sync`]. These types enable unsynchronized shared mutable state, which would be unsafe to transfer or share across threads.
+
 r[concurrency.send-and-sync.send]
 ### Send
 
@@ -24,7 +25,7 @@ The [`Send`] trait indicates that ownership of values of a type can be safely tr
 
 r[concurrency.send-and-sync.send.rules]
 1. A type that implements [`Send`] can be moved to another thread and used there without causing data races or other [undefined behavior].
-2. The Rust compiler automatically implements [`Send`] for types that satisfy its requirements (see the [`Send` documentation] for details on which types automatically implement this trait).
+2. The Rust compiler automatically implements [`Send`] for types that satisfy its requirements (see the [`Send` documentation] for examples of types that automatically implement this trait).
 3. Manually implementing [`Send`] is `unsafe`. Such implementations must ensure that moving a value of that type to another thread cannot violate Rust’s aliasing or mutability guarantees.
 
 r[concurrency.send-and-sync.send.auto-implementors]
@@ -49,7 +50,7 @@ The [`Sync`] trait indicates that references (`&T`) to a type can be safely shar
 
 r[concurrency.send-and-sync.sync.rules]
 1. If a type (`T`) is [`Sync`], then (`&T`) is [`Send`]: immutable references to type (`T`) can be sent to other threads and accessed there concurrently.
-2. The Rust compiler automatically implements [`Sync`] for types that satisfy its requirements (see the [`Sync` documentation] for details on which types automatically implement this trait).
+2. The Rust compiler automatically implements [`Sync`] for types that satisfy its requirements (see the [`Sync` documentation] for examples of types that automatically implement this trait).
 3. Manually implementing [`Sync`] is `unsafe`. Such implementations must ensure that concurrent shared access to values of that type cannot lead to data races or other [undefined behavior].
 
 r[concurrency.send-and-sync.sync.auto-implementors]
@@ -94,7 +95,7 @@ The following table lists the atomic types and the corresponding primitive types
 | `*mut T`       | [`core::sync::atomic::AtomicPtr<T>`]  |
 
 r[concurrency.atomics.usage]
-Atomic types are [`Sync`], meaning references to them can be safely shared between threads. However, atomic operations operate at the hardware level and require careful reasoning about memory ordering. Most programs should prefer higher-level concurrency primitives such as [`Mutex`] or [`RwLock`] unless fine-grained lock-free programming is required. While atomic operations prevent [data races] at the hardware level, they do not inherently enforce higher-level invariants. Complex coordination may still require locks or other synchronization primitives.
+Atomic types are [`Sync`], meaning references to them can be safely shared between threads. Using atomic operations correctly may require careful reasoning about memory ordering.
 
 r[concurrency.asynchronous-computation]
 ## Asynchronous Computation
@@ -110,9 +111,8 @@ The result of a future is obtained in one of two ways:
 1. Using an [`await` expression] (`future.await`), which implicitly polls the future until it is ready.
 2. By explicitly invoking [`core::future::Future::poll`].
 
-r[concurrency.async.rules]
-1. Once a future has returned [`core::task::Poll::Ready`], it must not be polled again.
-2. Polling a future that has already completed is [undefined behavior].
+r[concurrency.async.rule]
+Once a future has returned [`core::task::Poll::Ready`], it must not be polled again. Doing so may panic, block forever, or cause other kinds of problems.
 
 r[concurrency.async.closures]
 ### Async Closures