As I pointed out in another reply, I am fairly certain the atomic operations must be valid in these cases due to the happens before relationship of them and mutexes.
I don’t agree that returning the channel is a proper design, it breaks the encapsulation. Technically mine could use multiple channels behind the scenes - yours cannot. > On Sep 1, 2019, at 3:06 AM, roger peppe <rogpe...@gmail.com> wrote: > > The problem seems to be that you're using runtime.GOMAXPROCS. The fact that > using GOMAXPROCS causes a deadlock is probably a bug, but it's an easy one to > work around - just don't call it :) > > FWIW here's a version of your code that I'd consider a little more idiomatic. > > https://play.golang.org/p/ufLXXX1zbrn > > - it reports true when an operation succeeds rather than when it fails (think > reading from a channel or from a map). > - it removes the unnecessary (and probably wrong) atomic load > - it allows direct access to the channel for reading (and select etc) - no > need to hide it behind the Read method. > - mutex fields are very often named "mu" > > cheers, > rog. > >> On Sat, 31 Aug 2019 at 23:13, robert engels <reng...@ix.netcom.com> wrote: >> The code at https://play.golang.org/p/9ZdPVvwyaYK >> >> should not deadlock. But it reports: >> >> fatal error: all goroutines are asleep - deadlock! >> >> But if you look at the stack traces, you see multiple routines (sampled) >> like: >> >> goroutine 1 [sleep]: >> runtime.goparkunlock(...) >> /usr/local/go/src/runtime/proc.go:307 >> time.Sleep(0x3e8, 0x0) >> /usr/local/go/src/runtime/time.go:105 +0x1c0 >> main.main() >> /tmp/sandbox327672725/prog.go:81 +0x140 >> >> goroutine 5 [sleep]: >> runtime.goparkunlock(...) >> /usr/local/go/src/runtime/proc.go:307 >> time.Sleep(0x1, 0x0) >> /usr/local/go/src/runtime/time.go:105 +0x1c0 >> main.producer(0x430150, 0x40a0e0) >> /tmp/sandbox327672725/prog.go:49 +0x60 >> created by main.main >> /tmp/sandbox327672725/prog.go:73 +0xe0 >> >> These routines are asleep, not blocked. They will awake from sleep >> (eventually) - so there cannot be a deadlock. >> >> I am assuming this is a limitation of the Go playground back-end, but I >> can’t see it documented anywhere? Also, I’m not sure why this limitation >> would exist, since if all the routines are asleep or blocked, it is >> consuming no resources. >> >> Ideas? >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/AC9DEEBD-37DF-49FA-8171-E45418584697%40ix.netcom.com.
