Re: [go-nuts] sync.Cond implementation

Much appreciated for all the great advises from everyone. Or to be more precise: it is crucial you load wait before notify and the > check for equality can only happen if the routine "caught up". Also, your > proof must hold if you remove the fast-path check in line 522. > Why is it crucial to

Re: [go-nuts] sync.Cond implementation

Could it be this: Initially wait == notify == 0 Waiter Signaler 479 atomic.Xadd(&l.wait, 1) = 1 522 atomic.Load(&l.wait) = 0 atomic.Load(&l.notify) = 0 523 return (because those above are equal) 485 notifyListWait(l, t) (blocked forever) But looking at your answer, I see that you may imply c

[go-nuts] sync.Cond implementation

Hi Gophers! I'm trying to understand line 522 of src/runtime/sema.go : if atomic.Load(&l.wait) == atomic.Load(&l.notify) { > > ... I can't help but thinking, what guarantee that the atomic read of l.wait won't return s

Re: [go-nuts] (Un)Expected compiler behavior on named/unnamed parameters of interface functions

7, Ian Lance Taylor wrote: > > On Fri, Aug 11, 2017 at 11:03 AM, Penguin Enormous > > wrote: > > > > I think that there is inconsistency in the way Go compiler report error > > regarding name/unnamed parameters. This is a bit hard for me to explain > in &

[go-nuts] (Un)Expected compiler behavior on named/unnamed parameters of interface functions

I think that there is inconsistency in the way Go compiler report error regarding name/unnamed parameters. This is a bit hard for me to explain in words so please check out this short snippet first: https://play.golang.org/p/Sg0DtCtgF2 Is this unexpected behavior or it's just me that's feeling