I have misgivings about such long spinlocks in user space. A millisecond is over a million instructions.
Does the spinlock last a millisecond? It sounds from the article that it lasts 120 cycles.
It differs by CPU model.
Golang Sync Mutex: Normal and Starvation Mode
11–15 of 15 posts
Re: Golang Sync Mutex: Normal and Starvation Mode
#12> 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 so…
> 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 myInt;
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!
Re: Golang Sync Mutex: Normal and Starvation Mode
#13Earlier quoted context omitted.
Does the spinlock last a millisecond? It sounds from the article that it lasts 120 cycles.
It differs by CPU model.
So some CPU models wait 120 cycles and others wait a millisecond (millions of cycles)? That seems like a pretty drastic difference. I wonder why they would write code with such a drastic difference between CPU models.
Re: Golang Sync Mutex: Normal and Starvation Mode
#14> 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?
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.
Re: Golang Sync Mutex: Normal and Starvation Mode
#15Earlier quoted context omitted.
It differs by CPU model.
So some CPU models wait 120 cycles and others wait a millisecond (millions of cycles)? That seems like a pretty drastic difference. I wonder why they would write code with such a drastic difference between CPU models.
No, Haswell's PAUSE is 9 cycles, the P-cores of Alder Lake are 160 cycles. Zen 4 is 65.