Concurrency and Mutex lock with Thread spawns

[brson]

@ltfschoen

Why is it that sometimes when I run the Code Snippet the output is as shown in (A) below, whilst at other times the output is as shown in (B) below?:

spawn creates a new thread that executes concurrently with the main thread. When you try to get lock the mutex immediately after spawning, sometimes the other running thread is in the middle of holding the lock, others not.

@ltfschoen

Why doesn't the last element of the Vector get incremented (even if I apply a longer delay before the final println!). The output never appears to become Mutex { data: [2, 3, 4] }

The second bound in range syntax is exclusive, so 0..2 iteraters over 0 and 1 only.

@ltfschoen

It is my understanding that Thread::spawn returns a "detached" New Thread directly, whereas using Thread::scoped returns a Join Guard from which the Thread may be extracted. Does an RAII-style Join Guard (or any form of Guard at all) get returned when using Thread::spawn that will block until the New Thread is terminated? Or are Guards not relevant when just using Thread::spawn?

No, the JoinHandle returned by spawn does not block on destruction, but you can block on it by calling .join().

@ltfschoen

What does the statement "perform low-level synchronization" mean in the context of each New Thread that is returned when using Thread::spawn? How does this work and what does it achieve?

I'm not sure where this quote is from.

@ltfschoen

In the following Concurrency code snippet Arc pointer type has been used so that the "Send" Trait may be implemented in order to allow a "guard" to be transferred across Thread boundaries (when using "scoped" Threads), and to check with the Rust ownership system that its contents implement the "Sync" Trait ("Atomic" and safe to share across multiple threads).

You are using an Arc to share the Mutex value, which implements Sync, indicating that it can be shared between threads. There is no scoped thread in your example.

@ltfschoen

The clone() method is called upon the original Vector to perform Arc (Automatic Reference Counted) and increase the internal count for memory stack allocation and deallocation bookkeeping.

Yes, clone bumps the atomic ref count so that multiple pointers to the same Mutex can be shared between your threads. The ref count tracks the heap allocation that holds the Mutex, not the stack memory, though clone produces another copy of the Arc, which itself lives on the stack (containing a pointer to the Mutex on the heap).

@ltfschoen

The Mutex type ensures only one person may mutate the value of the of its Vector contents at a time, and has a lock() method that must be called to try and open the lock, and upon success the unwrap() method may be called to retrieve and mutate its data contents Vector.

Yes.

@ltfschoen

In the block where the New Thread is spawned ("detached" from the Current Thread that it may outlive) we call the lock() method, acquire the Mutex lock successfully, and call unwrap() to retrieve a reference to the Vector data for subsequent mutation through incrementing the respective Vector element's value.

Yes.