Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
On Sun, Aug 05, 2018 at 12:12:04PM -0700, Marvin Stenger wrote: > And my point was, that a slow path protected with a lock surely can execute > concurrently with a fast path not protected by that lock. So for the fast > path implementation one has to know what one is doing and if reordering > issues are a concern or not or if there could even be real data races on > the shared resource if accessed non-atomically. An additional piece of the puzzle is probably that this particular code is distributed together with the compiler and thus is allowed to make certain assumptions with regards to its behaviour. Would it be correct for user code to do something similar and rely on it to work across different Go implementations? I don't think it's written down anywhere how atomic reads are supposed to interact with non-atomic writes. But then, the same is true for basically everything sync/atomic. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
On Sun, Aug 5, 2018 at 12:12 PM, Marvin Stenger wrote: > > We talk about the implementation of chansend/recv, where fast paths are not > protected by a locked mutex (slow paths of course are). And those fast paths > use atomic.Loads intentially sparse, which could look inconsistent if not > familiar with the design/mechanics behind it. > And my point was, that a slow path protected with a lock surely can execute > concurrently with a fast path not protected by that lock. So for the fast > path implementation one has to know what one is doing and if reordering > issues are a concern or not or if there could even be real data races on the > shared resource if accessed non-atomically. Yes, it is definitely possible to get things wrong when combining a fast path not protected with a mutex with a slow path that is protected by a mutex. But it is also possible to get things right. Do you see a specific problem in the code? Ian -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
On Sun, Aug 5, 2018 at 9:01 PM Marvin Stenger wrote: > What: Code path protected by a mutex > Does what: does not execute concurrently > Surely it can execute concurrently, and even in parallel if your machine has more than one core. Then we are using the same word for different meanings, hence the confusion. By a mutex I mean this: https://en.wikipedia.org/wiki/Mutual_exclusion and in this meaning there's no concurrent execution of the code path protected by a mutex. -- -j -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
On Sun, Aug 5, 2018 at 8:25 PM Marvin Stenger wrote: > Well it does. Does what? Even, what does what? > For this this case of chan.go there are multiple reasons working together, why it is ok to sometimes use a lock, othertimes only atomic access or even plain access: Maybe I misunderstand something. Are we both talking about a code path protected by a locked mutex and thus executing in a single goroutine with no other goroutine concurrently accessing the data protected by the mutex, ie. in a way such that no two goroutines read _and_ write the same data within the protected path? (Concurrent reads, but only reads are ok.) -- -j -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
On Sun, Aug 5, 2018 at 7:28 PM wrote: > It is also my understanding that writes within a locked region that are read in some fast path without holding the lock need to be atomic writes. And the write to c.closed in closechan is NOT atomic. Code path protected by a mutex does nor execute concurrently. No need for atomic R/W ops. -- -j -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
I have read those comments. However, I still can't understand why it is safe for chansend to NOT use atomic.Load for c.closed when chanrecv does use it. It is also my understanding that writes within a locked region that are read in some fast path without holding the lock need to be atomic writes. And the write to c.closed in closechan is NOT atomic. -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?
The write to c.closed in closechan is *NOT* using atomic.Store. On Saturday, August 4, 2018 at 5:36:22 PM UTC-7, gra...@berkeley.edu wrote: > > I was taking a look at runtime/chan.go and noticed the following: > >- c.closed is accessed without taking c.lock in the fast paths of >chansend and chanrecv. In chansend it is accessed without using >atomic.Load, while in chanrecv it is accessed using atomic.Load. The write >to c.closed in closechan is using atomic.Store. >- something similar also is also happening with c.qcount > > > Is this intentional/safe? My understanding is that it is not safe and this > section from runtime/HACKING.md seems to agree: > > > “ > > Some common patterns that mix atomic and non-atomic access are: > > > Read-mostly variables where updates are protected by a lock. Within the > locked region, reads do not need to be atomic, but the write does. Outside > the locked region, reads need to be atomic.” > > > > It seems like reads to c.closed in both fast paths need to go through > atomic.Load and the write to c.closed in closechan needs to go through > atomic.Store. > -- 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. For more options, visit https://groups.google.com/d/optout.
