@@ -201,10 +201,10 @@ impl<T:Send> MutexArc<T> {
201201 * The reason this function is 'unsafe' is because it is possible to
202202 * construct a circular reference among multiple Arcs by mutating the
203203 * underlying data. This creates potential for deadlock, but worse, this
204- * will guarantee a memory leak of all involved Arcs. Using mutex Arcs
204+ * will guarantee a memory leak of all involved Arcs. Using MutexArcs
205205 * inside of other Arcs is safe in absence of circular references.
206206 *
207- * If you wish to nest mutex_arcs , one strategy for ensuring safety at
207+ * If you wish to nest MutexArcs , one strategy for ensuring safety at
208208 * runtime is to add a "nesting level counter" inside the stored data, and
209209 * when traversing the arcs, assert that they monotonically decrease.
210210 *
@@ -272,9 +272,9 @@ impl<T:Freeze + Send> MutexArc<T> {
272272 * requires the Freeze bound, which prohibits access on MutexArcs which
273273 * might contain nested MutexArcs inside.
274274 *
275- * The purpose of this is to offer a safe implementation of both methods
276- * access and access_cond to be used instead of rwlock in cases where no
277- * readers are needed and sightly better performance is required.
275+ * The purpose of this is to offer a safe implementation of MutexArc to be
276+ * used instead of RWArc in cases where no readers are needed and sightly
277+ * better performance is required.
278278 *
279279 * Both methods have the same failure behaviour as unsafe_access and
280280 * unsafe_access_cond.
0 commit comments