@@ -201,10 +201,10 @@ impl<T:Send> MutexArc<T> {
201
201
* The reason this function is 'unsafe' is because it is possible to
202
202
* construct a circular reference among multiple Arcs by mutating the
203
203
* 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
205
205
* inside of other Arcs is safe in absence of circular references.
206
206
*
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
208
208
* runtime is to add a "nesting level counter" inside the stored data, and
209
209
* when traversing the arcs, assert that they monotonically decrease.
210
210
*
@@ -272,9 +272,9 @@ impl<T:Freeze + Send> MutexArc<T> {
272
272
* requires the Freeze bound, which prohibits access on MutexArcs which
273
273
* might contain nested MutexArcs inside.
274
274
*
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.
278
278
*
279
279
* Both methods have the same failure behaviour as unsafe_access and
280
280
* unsafe_access_cond.
0 commit comments