Extra impl for (not-unsafe) Freeze version of MutexARC accessor methods

[bblum]

MutexARC and RWARC both make opposite choices for two different design features (safety-vs-nesting and rwlock-vs-mutex), excluding the other two combinations. We could permit the other combinations simply by adding extra impls with stub methods that called out to their counterpart.

[bblum]

Actually, there cannot be a non-freeze version of RWArc, even if it's labelled "unsafe" because of nesting. The entire point there is that the freeze requirement on RWArc contents enable the immutable read-mode. So, renaming this issue.

However, we could still have dual impls for the MutexArc, as the MutexArc only has a mutable access mode. A safe access mode for Send+Freeze MutexArc contents would be desirable to users who wish to have slightly better performance (mutexes are faster than rwlocks) and don't require a read mode.

I envision the current "access" and "access_cond" methods on MutexArc being changed to "unsafe_access" and "unsafe_access_cond", and having the prior names be used in the safe impl. (The constructors and unwrap method are safe even if the data doesn't freeze.)

Unassigning myself; this should be a pretty approachable code refactor for a newcomer.

[flaper87]

I'd like to take this one!

[bblum]

OK

[flaper87]

What would be the advantage of keeping unsafe_access and unsafe_access_cond ?

[bblum]

there should be two impls, one for each combination of kinds.

[flaper87]

r=?

[huonw]

@flaper87 have you opened a pull request with that commit?

[flaper87]

Just did! Damn, GH failed me before!

Thanks for the comment!

[flaper87]

r=?