Re: [go-nuts] playground - time.Sleep causes deadlock

Actually, in thinking about this some more, the atomics are completely unnecessary. Your solution being the best, but even without it, the channels create a happens before scenario - between the write of closed and “the channel close” and the read of closed. That is, for a channel to be

Re: [go-nuts] playground - time.Sleep causes deadlock

As far as I know you are attributing properties to the memory model that don’t yet exist - they’re working on it. Even the “happens before” in relation to atomics is not yet defined. The position from the Go “team” so far has been, whatever the behavior you see, that’s the spec (in terms of

Re: [go-nuts] playground - time.Sleep causes deadlock

On Mon, 2 Sep 2019, 21:32 robert engels, wrote: > (you’re comments were quoted, but I think I am replying correctly). > > The memory barriers provided by the Write Lock, and release will force the > flush to memory of all mutations before the flush (the closed mutation) - > meaning the atomic

Re: [go-nuts] playground - time.Sleep causes deadlock

(you’re comments were quoted, but I think I am replying correctly). The memory barriers provided by the Write Lock, and release will force the flush to memory of all mutations before the flush (the closed mutation) - meaning the atomic read will read the correct value. There is a chance that a

Re: [go-nuts] playground - time.Sleep causes deadlock

> > Btw, the removing of the GOMAXPROCS causes things to execute serially- > which is fine according to the spec - but it does make demonstrating > certain concurrency structs/problems pretty difficult. > > Unless something's changed recently, all programs in the playground > execute without

Re: [go-nuts] playground - time.Sleep causes deadlock

Btw, the removing of the GOMAXPROCS causes things to execute serially- which is fine according to the spec - but it does make demonstrating certain concurrency structs/problems pretty difficult. > On Sep 1, 2019, at 7:05 AM, robert engels wrote: > > The point about ‘mu’ is valid. Rather than

Re: [go-nuts] playground - time.Sleep causes deadlock

The point about ‘mu’ is valid. Rather than ‘closed’, it should really be an ‘error’ given the situation - as it is more applicable to the operation failures (as a black box IO component). > On Sep 1, 2019, at 6:46 AM, Robert Engels wrote: > > As I pointed out in another reply, I am fairly

Re: [go-nuts] playground - time.Sleep causes deadlock

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

Re: [go-nuts] playground - time.Sleep causes deadlock

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.

Re: [go-nuts] playground - time.Sleep causes deadlock

see the "faking time" section here: https://blog.golang.org/playground not sure if anything has changed since that article On Sat, Aug 31, 2019 at 4:22 PM robert engels wrote: > Yes, the code runs fine locally. Reviewing the playground docs, it sees > that at one point time.Sleep() was a no-op

Re: [go-nuts] playground - time.Sleep causes deadlock

Yes, the code runs fine locally. Reviewing the playground docs, it sees that at one point time.Sleep() was a no-op and it was changed. I am thinking that in the course of that change, they forgot to change the ‘deadlock’ detector. > On Aug 31, 2019, at 5:17 PM, burak serdar wrote: > > On Sat,

Re: [go-nuts] playground - time.Sleep causes deadlock

On Sat, Aug 31, 2019 at 4:13 PM robert engels wrote: > > The code at https://play.golang.org/p/9ZdPVvwyaYK > > should not deadlock. But it reports: I had the same problem the other day. Code runs locally, but not on playground. It also had a sleep in a goroutine. > > fatal error: all

[go-nuts] playground - time.Sleep causes deadlock

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]: