sync: WaitGroup is still confusing #24010
Comments
|
This has already been documented more in the past. (bc64c07 for #8543) I don't think more words will help at this point. If one is trying to use WaitGroup with your own locking around it, that means they're either using it wrong, or haven't read the existing docs. Can you give a concrete example of the type of code you're expecting to be easier? Maybe you're looking for a different primitive. |
bradfitz
added
the
WaitingForInfo
bradfitz
changed the title
|
Thx for the quick response! @bradfitz
I did see that :)
I'm trying to synchronize RPCs with shutting down of the server. The RPCs are not serviced from a common place so I can't guarantee the Add() before the Wait() gets called. The behavior I'm looking for is for Add() and Wait() to be atomic and not race: the Add() calls that happen after Wait() should not affect the outcome of the Wait(). With my current use, Wait() races with Add() and causes a deadlock. I've fallen back to using a RWMutex, which also not very elegant and seems odd to be used as a barrier during server shutdown. |
|
Yeah, I think WaitGroup is just not the tool you need. This is probably best discussed on the mailing list where others can chime in. (i.e. this is more of a https://golang.org/wiki/Questions sort of thing) I'll watch the lists and chime in if I have anything unique to add after hearing more details. The requirements are still a bit unclear for me at this point, but I do know that WaitGroup is not changing at this point. |
Can you please elaborate ? According to the docs: "A WaitGroup waits for a collection of goroutines to finish", which is basically what I'm trying to doing. @bradfitz |
|
Also, I'm surprised that there is no well known pattern to synchronize server shutdown. I would assume that to be a frequent thing one has to deal with with golang.
The requirements are to make WaitGroup functions atomic, which they currently are not. |
|
@anshulpundir as previously requested, please move this discussion to one of our mailing lists or another forum. |
|
oops sorry! sure thing @cespare |
sync.WaitGroup is a synchronization primitive. But WaitGroup itself requires synchronization and linearization (of code execution), which defeats its purpose to some extent when using it to synchronize multiple go routines.
Additionally, the documentation should be made clearer to explicitly state that Add() and Wait() need to be synchronized using locks or called within the same execution stream.
What version of Go are you using (
go version)?go version go1.9.1 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?NA
What did you do?
Trying to use sync.WaitGroup in a "multi-threaded" application.
What did you expect to see?
sync.WaitGroup Add() and Wait() should not cause data races and work with concurrent usage without external synchronization.
What did you see instead?
sync.WaitGroup Add() and Wait() cause data races.
The text was updated successfully, but these errors were encountered: