Can someone knowledgable explain what a mutex is, what a spinlock is, and the difference between mutexes and spinlocks?
The difference is actually in the implementation of the mutual exclusion. A mutex is generally a system call which often starts as a spin lock before the system call is invoked (which is an assembly routine that changes the process privilege level and cedes control to the host operating system). A spinlock literally "spins" in a loop until an atomic flag or semaphore indicates that it can enter the protected region. When it does, it atomically sets the flag so that it has exclusive access. Because a spinlock does not interact directly with the OS scheduler, it needs a pause instruction or yield syscall at some point in its loop (or every few interations). Failure to do so introduces pathological scheduling problems as outlined in the article.
Spinlocks are sometimes used because it is believed that the odds of a collision are very low, and the cost of a syscall is perceived as being high to the developer. However, it's something that should only be used if you know what you're doing, and its behavior is subject to not only the OS, but also the hardware you run on.
The spinlocking child will react to his arrival faster, but the sleeping (mutex) child makes a more efficient use of your attention.
Spinlock is a mutex algorithm based on spinning until the mutex is available.
Mutex is a MUTual EXclusion abstraction. A spinlock is one implementation. But spinlocks are problematic (for lots of reasons) so most of the time when someone says they’ve got a mutex it’s actually an adaptive lock:
- It has a fast path to acquire the lock.
- It may or may not be fair.
- It has a slow path that may enqueue the thread and deschedule it, but that slow path may have some adaptive spinning for a finite amount of time.
A mutex can also refer to a particular group of “mutual exclusion” methods where in the current process/thread is suspended until the condition is true.
Hope this helps.
Typically mutex / spinlock is implemented to reduce and prevent race conditions
It's still there. It's just a compile-time "race checker", not runtime.
Since in Rust it is illegal for a value to be referenced for writing in one place and referenced for anything else in any other place, regardless of concurrency/parallelism, Rust code is data-race free by design.
I still think that GP's comment was a non-sequitur.
Go's race detection says (with a high probability) you do or do not have any data races in the paths actually taken during some execution of your program. It is a (probabilistic) guarantee about how you ran your program.
Do you have some links about the known soundness issues? I was under the impression that although it hadn't yet been proven it was still a medium-term goal, and any soundness bugs were considered fairly major.
(And yeah, "mathematical proof" is strong regardless since e.g. LLVM is also in there somewhere. But it captures the idea more closely than any comparison of "compile vs. runtime" or "static vs. dynamic" does.)
Problem
1. We have a process with multiple threads of execution (e.g. A and B).
2. A and B will at some point act on the same data or object state.
3. Both A and B can't operate on the same data at the same time.
Mutexes function more or less as locks. They lock up your data to prevent unwanted race conditions. In multithreaded environments, a thread of execution has to acquire a mutex prior to accessing the data. Once it's done operating on the data, it releases the mutex so that another thread of execution can acquire it.
Mutexes are again, simply locks. But not all locks are the same. Locks come in different shapes and sizes and work in different ways. Same with mutexes, they can have different semantics.
Spinlocks are a kind of mutex that cause threads trying to acquire them to spin or loop around while waiting for the resource to be available.
I know what both a mutex and a spin lock are because I’m a developer myself but very much enjoy having my mind blown by someone on here who may have actually written the scheduler for Windows or Linux or be an expert of some sort.
When the article assumes reader knowledge (especially very specific stuff) tho... there are quite a few very good responses here, it'd be a shame to reduce them. There are some extremely knowledgeable people lurking around here, and they're sometimes doing so for this kind of reason - to spread the knowledge. Plus context-specific Q&A can be far more effective than random googling / other articles / etc, as a learning tool.