> Mutex, or MUTual EXclusion, in Go is basically a way to make sure that only one goroutine is messing with a shared resource at a time. This resource can be a piece of code, an integer, a map, a struct, a channel, or pretty much anything.
This is untrue right? It can only protect code, not data, right?
> This is untrue right? It can only protect code, not data, right?
Do traffic lights protect the flow of traffic, or do they protect people? It seems reductive to fixate on traffic lights stopping intersecting flows of traffic, when the intent is to ultimately protect people from slamming into (and thus injuring/killing) each other. It may be a tempting counterpoint that traffic lights don't do anything to protect someone from cancer, heart attack, etc -- but that's simply out of the scope of the protection that traffic lights are intended to provide.
Similarly, it seems odd to me to suggest that a mutex protects code -- what is it protecting that code from? How can the code be corrupted, damaged, or otherwise harmed? A mutex does prevent other non-lock-holding threads from running simultaneously, but that's all in service of protecting the data. The data is protected by imposing order on the execution of the code -- by serializing access to that data.
Controlling something isn't the same as protecting that something. A traffic light controls traffic, but it protects the people sharing the road. A mutex controls the execution of code, but it protects data.
> Do traffic lights protect the flow of traffic, or do they protect people? It seems reductive to fixate on traffic lights stopping intersecting flows of traffic, when the intent is to ultimately protect people from slamming into (and thus injuring/killing) each other.
Had the author of the article weighed in, then yes: They protect the flow of traffic, people, an int, pretty much anything!
> Similarly, it seems odd to me to suggest that a mutex protects code -- what is it protecting that code from?
It is protecting the code from simultaneous execution. The burden of protecting the data still falls on the programmer.
Mutexes literally appear so in the code. They wrap sections of imperative statements, or methods. They don't wrap data, eg:
Mutex<Int> myInt;
> Controlling something isn't the same as protecting that something. A traffic light controls traffic
Great example. Drivers die in intersections. The cause is driver inattention. The traffic lights don't lose their licence.
I only asked it as a question because others could hypothetically point out that Go mutexes can protect data (and NOT via metaphor) - maybe I missed something!
mutexes, in general, are considered to protect data. one associates a mutex with a piece of data. any number of bits of code might access that data, not just a single synchronized function.
"Starvation mode kicks in if a goroutine fails to acquire the lock for more than 1 millisecond."
That may mean that after 1ms, the mutex becomes more fair. That seems to be a further fallback than ending spinning.
Go tends to use only one real thread per CPU, so the problems are different than they are in, say, Rust. Go is doing some CPU dispatching in user space.
Readit News
This is untrue right? It can only protect code, not data, right?
Do traffic lights protect the flow of traffic, or do they protect people? It seems reductive to fixate on traffic lights stopping intersecting flows of traffic, when the intent is to ultimately protect people from slamming into (and thus injuring/killing) each other. It may be a tempting counterpoint that traffic lights don't do anything to protect someone from cancer, heart attack, etc -- but that's simply out of the scope of the protection that traffic lights are intended to provide.
Similarly, it seems odd to me to suggest that a mutex protects code -- what is it protecting that code from? How can the code be corrupted, damaged, or otherwise harmed? A mutex does prevent other non-lock-holding threads from running simultaneously, but that's all in service of protecting the data. The data is protected by imposing order on the execution of the code -- by serializing access to that data.
Controlling something isn't the same as protecting that something. A traffic light controls traffic, but it protects the people sharing the road. A mutex controls the execution of code, but it protects data.
Had the author of the article weighed in, then yes: They protect the flow of traffic, people, an int, pretty much anything!
> Similarly, it seems odd to me to suggest that a mutex protects code -- what is it protecting that code from?
It is protecting the code from simultaneous execution. The burden of protecting the data still falls on the programmer.
Mutexes literally appear so in the code. They wrap sections of imperative statements, or methods. They don't wrap data, eg:
> Controlling something isn't the same as protecting that something. A traffic light controls trafficGreat example. Drivers die in intersections. The cause is driver inattention. The traffic lights don't lose their licence.
I only asked it as a question because others could hypothetically point out that Go mutexes can protect data (and NOT via metaphor) - maybe I missed something!
That may mean that after 1ms, the mutex becomes more fair. That seems to be a further fallback than ending spinning.
Go tends to use only one real thread per CPU, so the problems are different than they are in, say, Rust. Go is doing some CPU dispatching in user space.