|
98 | 98 | //! location doesn't lead to undefined behavior.
|
99 | 99 | //!
|
100 | 100 | //! [prefetching]: https://en.wikipedia.org/wiki/Cache_prefetching
|
101 |
| -//! [compiler fences]: atomic::compiler_fence |
| 101 | +//! [compiler fences]: crate::sync::atomic::compiler_fence |
102 | 102 | //! [out-of-order]: https://en.wikipedia.org/wiki/Out-of-order_execution
|
103 | 103 | //! [superscalar]: https://en.wikipedia.org/wiki/Superscalar_processor
|
104 |
| -//! [memory fences]: atomic::fence |
105 |
| -//! [atomics operations]: atomic |
| 104 | +//! [memory fences]: crate::sync::atomic::fence |
| 105 | +//! [atomic operations]: crate::sync::atomic |
106 | 106 | //!
|
107 | 107 | //! ## Higher-level synchronization objects
|
108 | 108 | //!
|
|
120 | 120 | //! Higher-level synchronization mechanisms are usually heavy-weight.
|
121 | 121 | //! While most atomic operations can execute instantaneously, acquiring a
|
122 | 122 | //! [`Mutex`] can involve blocking until another thread releases it.
|
123 |
| -//! For [`RwLock`], while! any number of readers may acquire it without |
| 123 | +//! For [`RwLock`], while any number of readers may acquire it without |
124 | 124 | //! blocking, each writer will have exclusive access.
|
125 | 125 | //!
|
126 | 126 | //! On the other hand, communication over [channels] can provide a fairly
|
|
130 | 130 | //! The more synchronization exists between CPUs, the smaller the performance
|
131 | 131 | //! gains from multithreading will be.
|
132 | 132 | //!
|
133 |
| -//! [channels]: mpsc |
| 133 | +//! [`Mutex`]: crate::sync::Mutex |
| 134 | +//! [`RwLock`]: crate::sync::RwLock |
| 135 | +//! [channels]: crate::sync::mpsc |
134 | 136 |
|
135 | 137 | #![stable(feature = "rust1", since = "1.0.0")]
|
136 | 138 |
|
|
0 commit comments