Skip to content

Commit d0ad251

Browse files
committed
Use MuextArc and RWArc in docstrings
1 parent c0aa62c commit d0ad251

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

src/libextra/arc.rs

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)