You're getting some incomplete answers to your question. Both a mutex and a spinlock is used to guarantee that a set of instructions are only invoked by a single thread of computation at once (with some variation; some mutex types permit multiple readers for example).

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.

One child asks, "are we there yet?" continuously until the answer changes. The other asks you to wake her once you get there, and goes to sleep.

The spinlocking child will react to his arrival faster, but the sleeping (mutex) child makes a more efficient use of your attention.

These are words that don’t necessarily mean different things. In the broadest sense of mutex and the strictest sense of spinlock, every spinlock is a mutex.

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 spinlock is a kind of mutex (“mutual exclusion”) where in a condition is checked as fast as possible in a loop. This is useful when the expected wait times are short as you don’t have to pay the context switch penalty. Typically done when you have real parallelism with multiple CPUs/cores.

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.

Additional note that mutual exclusion is a concept that pops up a lot when dealing with concurrent processing (think threads, multi-process type architectures).

Typically mutex / spinlock is implemented to reduce and prevent race conditions

One can see this at a higher level in Golang, where a gofunc are reading/updating a map - and run with -race then it shows where you have to use a Mutex call to lock that Map for the access, R or RW. Higher level but pretty simple to see.

One can see this at an even higher level in Rust, where you don't even need a "race checker" to avoid data races in safe code - the compiler will force the use of patterns like Mutex<> or Rwlock<> (or others) for stuff that might be accessed concurrently in ways that would otherwise break mutual exclusion.

I was trying to show the problem-pattern space so others could learn. It's not about the wand, it's about showing the spells.

So what would you call the application of the compiler enforcing non-race condition patterns of it's not a "race checker"?

It's still there. It's just a compile-time "race checker", not runtime.

Not really, in Rust's case. It's the general borrow checker which handles this.

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.

Rust has "interior" mutability, meaning that shared references are not true 'read only' references; they can be used for writing if the type supports such an operation. What makes Rust data-race free is the combination of 'interior' mutability and the Send and Sync traits, which control moving or referencing objects across threads.

Rust's compiler checks a mathematical proof that, if your types are valid (e.g. you didn't do anything bad during `unsafe`) you do not have any data races. It is a guarantee about your program per se.

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.

It's not a mathematical proof in the literal sense (yet), because there are known soundness bugs in Rust that are yet to be addressed; moreover the interaction of borrow checking (including interior mutability) with the traits system is poorly understood and has not been proven to be correct even in a simplified model. It should yield a meaningful level of checking, and if nothing else, the ergonomics is way better than just running a static analysis on C/C++ code (setting aside the question of whether current static analysis tools can even check for possible data races); but you shouldn't rely on it to that extent.

I don't program Rust regularly or track its status in that much detail, so thanks for the correction.

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.)

https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao... is the list of soundness bugs. They are considered major, but they’re more compiler bugs than something broken in the language itself. They are taken seriously, but bugs will always happen. Some need upstream fixes, too, so that can take a while.

Mutex and Spinlocks are abstractions / programming language constructs used to solve the following class of problems:

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.

The first sub-section of the article is "Defining Mutexes and Spinlocks"

Thanks. It would be great to eliminate "can anyone", "can someone", and ELI5 from HN in 2020. We're literally conversing through the worlds largest connected and searchable knowledge base (the internet), and don't need to encourage lazyweb.

I actually come here for explanations like these from from experts and HN lurkers instead of reading the pop-internet article that comes up first on google.

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.

Real experts aren't waiting on the internet to be the first response to lazyweb: they publish blog posts, papers, books, and tomes of knowledge, which are peer-reviewed and revised. Experts who have something valuable to add will eventually speak up, without being asked. I guarantee that answers to such low-quality questions primarily get low-quality responses. It's the Tragedy of the Commons of discussion sites.

I recently had a beginner question about actors and persistence addressed by carl hewitt here. I think you underestimate the kindness of extremely knowledgeable people ( and HN )

It's real easy to, even not being lazy, not know how to ask the question right to be able to find those tomes of knowledge.

Since it's covered quite simply and very visibly in the article: yea, this is one ELI5 I'd prefer to not exist. At least skimming TFA is a reasonable pre-requisite IMO.

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.