yes, It is a data race.
But the problem mentioned by op is not caused by data race.
On Tuesday, September 12, 2017 at 3:59:32 AM UTC-4, Konstantin Khomoutov
wrote:
>
> On Wed, Sep 06, 2017 at 04:26:09AM -0700, T L wrote:
>
> > > > It is just weird that the evaluation timing of *p is different to
On Wed, Sep 06, 2017 at 04:26:09AM -0700, T L wrote:
> > > It is just weird that the evaluation timing of *p is different to other
> > expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
> >
> > The value depends on a data race so it's entirely undefined in all cases.
> > That the actu
On Wednesday, September 6, 2017 at 7:38:04 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>>
>> On 6 Sep 2017, at 10:28, T L wrote:
>> > It is just weird that the evaluation timing of *p is different to other
>> expressions, such as, *p+0, *
On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>
> On 6 Sep 2017, at 10:28, T L > wrote:
> > It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
>
> The value depends on a data race so it
On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>
> On 6 Sep 2017, at 10:28, T L > wrote:
> > It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
>
> The value depends on a data race so it
On 6 Sep 2017, at 10:28, T L wrote:
> It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
The value depends on a data race so it's entirely undefined in all cases. That
the actual outcome then depends on trivial
On Tuesday, September 5, 2017 at 11:04:52 PM UTC-4, Jesse McNelis wrote:
>
> On Wed, Sep 6, 2017 at 2:26 AM, T L >
> wrote:
> >
> > I mean it can be viewed as a bug for inconsistency.
> > But from the memory model view, it can also not be viewed as a bug.
> >
>
> It's not a bug. The code is
On Wed, Sep 6, 2017 at 2:26 AM, T L wrote:
>
> I mean it can be viewed as a bug for inconsistency.
> But from the memory model view, it can also not be viewed as a bug.
>
It's not a bug. The code is clearly expecting some ordering between
internal operations within two goroutines, this is an inco
On Tuesday, September 5, 2017 at 12:20:02 PM UTC-4, T L wrote:
>
> IMO, I think this is a bug.
>
I mean it can be viewed as a bug for inconsistency.
But from the memory model view, it can also not be viewed as a bug.
>
> On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote:
>>
>> BTW
IMO, I think this is a bug.
On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote:
>
> BTW, the following one also prints 10.
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> var num = 10
> var p = &num
>
> c := make(chan int)
>
> go func() {
>
BTW, the following one also prints 10.
package main
import (
"fmt"
"time"
)
func main() {
var num = 10
var p = &num
c := make(chan int)
go func() {
c <- *p * 1 // with this line we will get 11 from channel c
//c <- num // with this line we will get 10 fr
The program is really racy, but the result is also really some
counter-intuitive.
The following program also print 10, which means evaluation of pointer
dereference
is some different to evaluation of other expressions in flow.
package main
import (
"fmt"
"time"
)
func main() {
var
On Tue, Sep 5, 2017 at 10:34 AM, Marlon Che wrote:
> Hi everyone!
> Please help me figure out the two different results of following code:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> var num = 10
> var p = &num
>
> c := make(chan int)
>
> go func(
Hi everyone!
Please help me figure out the two different results of following code:
package main
import (
"fmt"
"time"
)
func main() {
var num = 10
var p = &num
c := make(chan int)
go func() {
c <- *p // with this line we will get 11 from channel c
//c <
14 matches
Mail list logo
