Is there a name for the `Arc<Mutex<T>>` pattern?

For a program I'm writing I need (or – to be more precise – would like) a name for the pattern of wrapping a type in an Mutex and that in an Arc. Is there already an established one, because I couldn't find one?

Newbie here. While someone with experience answer you, my first thought is " allocated shared mutex " or " shared mutex " for shortness.

Arc is an thread oriented type with shared ownership immutable (read) what allocates but with small overhead.

Mutex is an thread oriented type with unique ownership mutable (read/write) what don't allocate.

The problem is, Mutex may nullify the advantage of an parallelized iterator due having to wait the sequential Mutex access.

So from my newbie limited understanding, it is a pattern what is taken when T is not a Sync type, or can not be designed/refactored as such, what means can not be used as an Arc<T> for being able to be accessed from multiple threads without fall in data-race.

What makes me rename in my thougts Arc<Mutex<T>> as " basic shared mutex ", or even " slow shared mutex ", if it is intended to be accessed intensively from multiple threads. If I understand right (I hope be wrong).

1 Like

The Rust book uses the term "shared state". I think that is the usual name.

1 Like

Probably "thread-safe shared mutable state", since Rc<RefCell> is also shared mutable state, just not thread-safe.

In general, I like to call things what they are and not invent names for better readability, so I have created wrapper types called RcCell in the past, for instance.

1 Like

All inter-task(thread) communication is relatively expensive, so if there is a lot of work to be done, you do not want tasks to be communicating at a very fine grained level, such a processing a single byte. Note that accessing data using Arc is efficient, it is only cloning the Arc (or otherwise needing to check the reference count) that is expensive. Once a task has an Arc ( which can be shared within the task using Rc if necessary ), access is cheap for read operations.