Go Sync.Cond, the Most Overlooked Sync Mechanism(victoriametrics.com)
victoriametrics.com
Go Sync.Cond, the Most Overlooked Sync Mechanism
https://victoriametrics.com/blog/go-sync-cond/index.html
5 comments
The article could be a bit misleading, as it focuses on the act of one goroutine signaling another. That’s why it emphasizes 'for its signaling to work.'
> "In theory, a condition variable like sync.Cond doesn’t have to be tied to a lock for its signaling to work."
It basically separates signaling from lock management, but not about removing the entire need for a mutex. From a pure technical POV, developers can totally handle locking and unlocking the mutex themselves to protect the process of dealing with shared resources, so it's not about technical limitation.
Including a mutex in sync.Cond and having it automatically unlock the mutex in cond.Wait() is an engineering decision that enforces us, developers, to call Lock() on the mutex beforehand and follow the pattern to avoid panic.
> "In theory, a condition variable like sync.Cond doesn’t have to be tied to a lock for its signaling to work."
It basically separates signaling from lock management, but not about removing the entire need for a mutex. From a pure technical POV, developers can totally handle locking and unlocking the mutex themselves to protect the process of dealing with shared resources, so it's not about technical limitation.
Including a mutex in sync.Cond and having it automatically unlock the mutex in cond.Wait() is an engineering decision that enforces us, developers, to call Lock() on the mutex beforehand and follow the pattern to avoid panic.
It is not an engineering decision. There is no way that a thread can safely unlock the mutex before the CV wait without risking missed wake-ups.
The mutex unlock and CV wait must be atomic for the CV to work correctly. There is no way around it.
The mutex unlock and CV wait must be atomic for the CV to work correctly. There is no way around it.
Indeed, that's the basic missed wake-up scenario for a signaling primitive.
With condition variables (as a general primitive, not specifically in Go) checking the for the condition and waiting must be done atomically, by holding the lock, as condition variables are stateless.
Evencounts and futexes (aka keyed events) are similar edge triggered primitives, but they don't require an user visible lock to be held as atomicity is guaranteed in other ways.
With condition variables (as a general primitive, not specifically in Go) checking the for the condition and waiting must be done atomically, by holding the lock, as condition variables are stateless.
Evencounts and futexes (aka keyed events) are similar edge triggered primitives, but they don't require an user visible lock to be held as atomicity is guaranteed in other ways.
[deleted]
> In theory, a condition variable like sync.Cond doesn’t have to be tied to a lock for its signaling to work. > You could have the users manage their own locks outside of the condition variable, which might sound like it gives more flexibility. It’s not really a technical limitation but more about human error.
I don't think this is true, if the concurrency model for goroutines may be assumed to be the same as regular OS threads. Assume the following:
1. You lock a shared resource (to be progressed by a worker goroutine)
2. You spawn the worker goroutine
3. You unlock the shared resource
4. It just so happens that the go runtime schedules the worker on a separate CPU, the worker now then progresses the resource to completion, and cond.Broadcast()'s
5. You now cond.Wait'() on a signal that will never arrive. (This cannot actually happen because Golang's cond.Wait() requires the lock to have been acquired before being called, and also locks before relinquishing control, so we're discussing the post author's version)
This was also the issue I noticed when I was considering using channels for signaling. The use case was:
1. I needed a worker goroutine that progressed a certain resource
2. I needed to fail anyway if the worker did not progress to completion at least within a timeout.
3. I needed to eagerly return asap if the worker progressed to completion before the timeout is done.
I initially considered spawning the worker goroutine and a timeout goroutine and doing a select on channels. But it turned out to be far easier done with a condition variable, especially if we needed to make sure that nothing eventually ends up blocking on sending to a channel that will never be listened to.