Re: [go-nuts] http: unexpected EOF reading trailer not a temporary error?

[Jens-Uwe Mager]

Looking further into this, I see this as a typical transient error in a bad 
network on downloading files. It may be different elsewhere, but I have to 
retry on that error as it appears. And I cannot change the network 
somewhere in the Guatemala outback.

On Monday, April 16, 2018 at 4:59:28 PM UTC-6, Ian Lance Taylor wrote:
>
> On Mon, Apr 16, 2018 at 3:09 PM, Jens-Uwe Mager  > wrote: 
> > 
> > I am checking net.error for the Temporary() condition, and in my very 
> bad 
> > network I do see really a lot of errors. While doing a GET request I see 
> > that 
> > 
> > http: unexpected EOF reading trailer 
> > 
> > is not a temporary error, so my retry logic does not kick in. Is this a 
> > special case or just an oversight? 
>
> EOF means that the TCP connection has closed, so this error is not 
> temporary. 
>
> 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] Why does the parallel version of a program runs slower?

[Tashi Lu]

Hi Lee,

Thanks for pointing out my misuse of words. 
I've actually borne in mind that parallelism and concurrency are different 
things, but I made a slip. 
I'll try to be more careful next time.

On Tuesday, 17 April 2018 04:09:06 UTC+8, Lee Painton wrote:
>
> Also, as Rob Pike has stressed in the past, concurrency is not 
> parallelism.  Concurrency is a design principle that enables parallelism, 
> but goroutines are concurrency constructs and do not automatically run in 
> parallel.
>
> On Monday, April 16, 2018 at 12:47:18 PM UTC-4, andrey mirtchovski wrote:
>>
>> In short, your concurrency is too fine-grained. Adding concurrency 
>> primitives requires locking which is expensive, and creating a lot of 
>> goroutines does consume resources, even if we consider it relatively 
>> cheap. 
>>
>> If you slice the problem slightly differently it can be made faster: 
>> one goroutine per number, but each goroutine calculates its number the 
>> "normal" way, without using concurrency: 
>>
>> https://play.golang.org/p/lKYSbuK79sB 
>>
>> $ time ./tt 20 > /dev/null # new code 
>>
>> real 0m3.374s 
>> user 0m5.129s 
>> sys 0m0.016s 
>>
>> $ time ./t 20 > /dev/null # your original non-concurrent program 
>>
>> real 0m4.593s 
>> user 0m4.538s 
>> sys 0m0.019s 
>>
>>
>>
>> On Mon, Apr 16, 2018 at 9:09 AM, Tashi Lu  wrote: 
>> > Hi all, 
>> > 
>> > As a newbie I tried to implement a simple program calculating the 
>> Catalan 
>> > numbers, which are the numbers satisfying the recursion equation c(1) = 
>> 1; 
>> > c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n). 
>> > 
>> > At first, I implemented it without channels: 
>> > package main 
>> > 
>> > import ( 
>> > "fmt" 
>> > "os" 
>> > "strconv" 
>> > ) 
>> > 
>> > func catalan(n int) int { 
>> > if n == 1 { 
>> > return 1 
>> > } 
>> > res := 0 
>> > for i := 1; i < n; i++ { 
>> > res += catalan(n - i) * catalan(i) 
>> > } 
>> > return res 
>> > } 
>> > 
>> > func main() { 
>> > n, _ := strconv.Atoi(os.Args[1]) 
>> > for i := 1; i <= n; i++ { 
>> > fmt.Println(catalan(i)) 
>> > } 
>> > } 
>> > 
>> > 
>> > Then I thought the calculation can be easily made concurrent, so I 
>> wrote the 
>> > version below: 
>> > package main 
>> > 
>> > import ( 
>> > "fmt" 
>> > "os" 
>> > "strconv" 
>> > ) 
>> > 
>> > func catalan(n int, ch chan int) { 
>> > if n == 1 { 
>> > ch <- 1 
>> > return 
>> > } 
>> > res := 0 
>> > for i := 1; i < n; i++ { 
>> > ch1 := make(chan int) 
>> > ch2 := make(chan int) 
>> > go catalan(n - i, ch1) 
>> > go catalan(i, ch2) 
>> > res += <-ch1 * <-ch2 
>> > close(ch1) 
>> > close(ch2) 
>> > } 
>> > ch <- res 
>> > } 
>> > 
>> > func main() { 
>> > n, _ := strconv.Atoi(os.Args[1]) 
>> > for i := 1; i <= n; i++ { 
>> > q := make(chan int) 
>> > go catalan(i, q) 
>> > fmt.Println(<-q) 
>> > close(q) 
>> > } 
>> > } 
>> > 
>> > 
>> > But I found the second version was unexpectly slower than the first: 
>> > go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total 
>> > vs 
>> > go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 
>> total 
>> > 
>> > What's the reason behind this? How can I improve this concurrent 
>> version to 
>> > make it faster? 
>> > 
>> > -- 
>> > 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...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
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] Why does the parallel version of a program runs slower?

[Tashi Lu]

Thanks Andrey.

I did realize the overhead of goroutines, but I didn't realize it was this 
large.

Your version is better, but it can't output results sequentially, sorting 
it before output is easy anyway.

One new thing I learned from your code is that channels can be reused. I 
thought every goroutine needs a new channel as you can see in my original 
code.

On Tuesday, 17 April 2018 00:47:18 UTC+8, andrey mirtchovski wrote:
>
> In short, your concurrency is too fine-grained. Adding concurrency 
> primitives requires locking which is expensive, and creating a lot of 
> goroutines does consume resources, even if we consider it relatively 
> cheap. 
>
> If you slice the problem slightly differently it can be made faster: 
> one goroutine per number, but each goroutine calculates its number the 
> "normal" way, without using concurrency: 
>
> https://play.golang.org/p/lKYSbuK79sB 
>
> $ time ./tt 20 > /dev/null # new code 
>
> real 0m3.374s 
> user 0m5.129s 
> sys 0m0.016s 
>
> $ time ./t 20 > /dev/null # your original non-concurrent program 
>
> real 0m4.593s 
> user 0m4.538s 
> sys 0m0.019s 
>
>
>
> On Mon, Apr 16, 2018 at 9:09 AM, Tashi Lu  > wrote: 
> > Hi all, 
> > 
> > As a newbie I tried to implement a simple program calculating the 
> Catalan 
> > numbers, which are the numbers satisfying the recursion equation c(1) = 
> 1; 
> > c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n). 
> > 
> > At first, I implemented it without channels: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "os" 
> > "strconv" 
> > ) 
> > 
> > func catalan(n int) int { 
> > if n == 1 { 
> > return 1 
> > } 
> > res := 0 
> > for i := 1; i < n; i++ { 
> > res += catalan(n - i) * catalan(i) 
> > } 
> > return res 
> > } 
> > 
> > func main() { 
> > n, _ := strconv.Atoi(os.Args[1]) 
> > for i := 1; i <= n; i++ { 
> > fmt.Println(catalan(i)) 
> > } 
> > } 
> > 
> > 
> > Then I thought the calculation can be easily made concurrent, so I wrote 
> the 
> > version below: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "os" 
> > "strconv" 
> > ) 
> > 
> > func catalan(n int, ch chan int) { 
> > if n == 1 { 
> > ch <- 1 
> > return 
> > } 
> > res := 0 
> > for i := 1; i < n; i++ { 
> > ch1 := make(chan int) 
> > ch2 := make(chan int) 
> > go catalan(n - i, ch1) 
> > go catalan(i, ch2) 
> > res += <-ch1 * <-ch2 
> > close(ch1) 
> > close(ch2) 
> > } 
> > ch <- res 
> > } 
> > 
> > func main() { 
> > n, _ := strconv.Atoi(os.Args[1]) 
> > for i := 1; i <= n; i++ { 
> > q := make(chan int) 
> > go catalan(i, q) 
> > fmt.Println(<-q) 
> > close(q) 
> > } 
> > } 
> > 
> > 
> > But I found the second version was unexpectly slower than the first: 
> > go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total 
> > vs 
> > go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 
> total 
> > 
> > What's the reason behind this? How can I improve this concurrent version 
> to 
> > make it faster? 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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] http: unexpected EOF reading trailer not a temporary error?

[Ian Lance Taylor]

On Mon, Apr 16, 2018 at 3:09 PM, Jens-Uwe Mager  wrote:
>
> I am checking net.error for the Temporary() condition, and in my very bad
> network I do see really a lot of errors. While doing a GET request I see
> that
>
> http: unexpected EOF reading trailer
>
> is not a temporary error, so my retry logic does not kick in. Is this a
> special case or just an oversight?

EOF means that the TCP connection has closed, so this error is not temporary.

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.

[go-nuts] http: unexpected EOF reading trailer not a temporary error?

[Jens-Uwe Mager]

I am checking net.error for the Temporary() condition, and in my very bad 
network I do see really a lot of errors. While doing a GET request I see 
that 

http: unexpected EOF reading trailer 

is not a temporary error, so my retry logic does not kick in. Is this a 
special case or just an oversight?

-- 
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] Why does the parallel version of a program runs slower?

[Lee Painton]

Also, as Rob Pike has stressed in the past, concurrency is not 
parallelism.  Concurrency is a design principle that enables parallelism, 
but goroutines are concurrency constructs and do not automatically run in 
parallel.

On Monday, April 16, 2018 at 12:47:18 PM UTC-4, andrey mirtchovski wrote:
>
> In short, your concurrency is too fine-grained. Adding concurrency 
> primitives requires locking which is expensive, and creating a lot of 
> goroutines does consume resources, even if we consider it relatively 
> cheap. 
>
> If you slice the problem slightly differently it can be made faster: 
> one goroutine per number, but each goroutine calculates its number the 
> "normal" way, without using concurrency: 
>
> https://play.golang.org/p/lKYSbuK79sB 
>
> $ time ./tt 20 > /dev/null # new code 
>
> real 0m3.374s 
> user 0m5.129s 
> sys 0m0.016s 
>
> $ time ./t 20 > /dev/null # your original non-concurrent program 
>
> real 0m4.593s 
> user 0m4.538s 
> sys 0m0.019s 
>
>
>
> On Mon, Apr 16, 2018 at 9:09 AM, Tashi Lu  > wrote: 
> > Hi all, 
> > 
> > As a newbie I tried to implement a simple program calculating the 
> Catalan 
> > numbers, which are the numbers satisfying the recursion equation c(1) = 
> 1; 
> > c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n). 
> > 
> > At first, I implemented it without channels: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "os" 
> > "strconv" 
> > ) 
> > 
> > func catalan(n int) int { 
> > if n == 1 { 
> > return 1 
> > } 
> > res := 0 
> > for i := 1; i < n; i++ { 
> > res += catalan(n - i) * catalan(i) 
> > } 
> > return res 
> > } 
> > 
> > func main() { 
> > n, _ := strconv.Atoi(os.Args[1]) 
> > for i := 1; i <= n; i++ { 
> > fmt.Println(catalan(i)) 
> > } 
> > } 
> > 
> > 
> > Then I thought the calculation can be easily made concurrent, so I wrote 
> the 
> > version below: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "os" 
> > "strconv" 
> > ) 
> > 
> > func catalan(n int, ch chan int) { 
> > if n == 1 { 
> > ch <- 1 
> > return 
> > } 
> > res := 0 
> > for i := 1; i < n; i++ { 
> > ch1 := make(chan int) 
> > ch2 := make(chan int) 
> > go catalan(n - i, ch1) 
> > go catalan(i, ch2) 
> > res += <-ch1 * <-ch2 
> > close(ch1) 
> > close(ch2) 
> > } 
> > ch <- res 
> > } 
> > 
> > func main() { 
> > n, _ := strconv.Atoi(os.Args[1]) 
> > for i := 1; i <= n; i++ { 
> > q := make(chan int) 
> > go catalan(i, q) 
> > fmt.Println(<-q) 
> > close(q) 
> > } 
> > } 
> > 
> > 
> > But I found the second version was unexpectly slower than the first: 
> > go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total 
> > vs 
> > go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 
> total 
> > 
> > What's the reason behind this? How can I improve this concurrent version 
> to 
> > make it faster? 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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] sync.Cond implementation

[Ian Lance Taylor]

On Sat, Apr 14, 2018 at 10:02 AM, Penguin Enormous
 wrote:
>
> Could it be this:
>
> Initially wait == notify == 0
>
> Waiter  Signaler
>
> 479 atomic.Xadd(, 1) = 1
>
> 522 atomic.Load() = 0
> atomic.Load() = 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 certain race conditions
> are allowed. Could you explain a bit more on that? Aren't race conditions
> supposedly bad?
>
> If atomic load should always returns the last atomic write to a memory
> location and if I make absolutely sure that the last atomic write finish at
> a specific time instant earlier than the atomic load, I can never get data
> written before that last atomic write, is that what you meant?

I didn't mean to imply that data races are OK.  I meant that when
using condition variables, you have to be aware of the race conditions
between Wait and Signal/Broadcast, and you have to mitigate those race
conditions through correct use of the Locker associated with the
condition variable.  These race conditions are not data race
conditions, they are rather logical race conditions, in the sense that
if you do not correctly use the Locker then your goroutines can indeed
block forever in Wait.

You are describing the possible race in terms of the runtime code,
which is the wrong level.  You need to try to describe it in terms of
the sync.Cond methods.  If you do that you see that the atomic
increment of l.wait is done with Locker locked.  Then the Locker is
unlocked, and the code calls notifyListWait.  The loads of l.wait and
l.notify are done by the Signal and Broadcast methods.  While the
Signal and Broadcast methods do not require the Locker to be locked,
if you want to ensure that they wake up all waiting goroutines there
must be some sort of happens-before relationship between the waiting
goroutine and the signaling goroutine.  If there is no happens-before
relationship, then in theory the signal could happen before the wait,
in which case obviously the wait won't see the signal; that's just how
condition variables work.  For your program to work as expected, it
must be the case that the wait happens-before the signal.  And the
obvious way to do that is to acquire the lock before signaling.
Acquire the lock, verify that there is something to signal, and then
signal (releasing the lock before signaling is optional).

This is how condition variables work in any language, it's not specific to Go.

And this is the reason why condition variables are very rarely used in
Go.  It is much easier to reason correctly about channels and mutexes
than it is to reason about condition variables.  Therefore, Go
programs prefer channels and mutexes when at all possible.

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] Why does the parallel version of a program runs slower?

[andrey mirtchovski]

In short, your concurrency is too fine-grained. Adding concurrency
primitives requires locking which is expensive, and creating a lot of
goroutines does consume resources, even if we consider it relatively
cheap.

If you slice the problem slightly differently it can be made faster:
one goroutine per number, but each goroutine calculates its number the
"normal" way, without using concurrency:

https://play.golang.org/p/lKYSbuK79sB

$ time ./tt 20 > /dev/null # new code

real 0m3.374s
user 0m5.129s
sys 0m0.016s

$ time ./t 20 > /dev/null # your original non-concurrent program

real 0m4.593s
user 0m4.538s
sys 0m0.019s



On Mon, Apr 16, 2018 at 9:09 AM, Tashi Lu  wrote:
> Hi all,
>
> As a newbie I tried to implement a simple program calculating the Catalan
> numbers, which are the numbers satisfying the recursion equation c(1) = 1;
> c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n).
>
> At first, I implemented it without channels:
> package main
>
> import (
> "fmt"
> "os"
> "strconv"
> )
>
> func catalan(n int) int {
> if n == 1 {
> return 1
> }
> res := 0
> for i := 1; i < n; i++ {
> res += catalan(n - i) * catalan(i)
> }
> return res
> }
>
> func main() {
> n, _ := strconv.Atoi(os.Args[1])
> for i := 1; i <= n; i++ {
> fmt.Println(catalan(i))
> }
> }
>
>
> Then I thought the calculation can be easily made concurrent, so I wrote the
> version below:
> package main
>
> import (
> "fmt"
> "os"
> "strconv"
> )
>
> func catalan(n int, ch chan int) {
> if n == 1 {
> ch <- 1
> return
> }
> res := 0
> for i := 1; i < n; i++ {
> ch1 := make(chan int)
> ch2 := make(chan int)
> go catalan(n - i, ch1)
> go catalan(i, ch2)
> res += <-ch1 * <-ch2
> close(ch1)
> close(ch2)
> }
> ch <- res
> }
>
> func main() {
> n, _ := strconv.Atoi(os.Args[1])
> for i := 1; i <= n; i++ {
> q := make(chan int)
> go catalan(i, q)
> fmt.Println(<-q)
> close(q)
> }
> }
>
>
> But I found the second version was unexpectly slower than the first:
> go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total
> vs
> go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 total
>
> What's the reason behind this? How can I improve this concurrent version to
> make it faster?
>
> --
> 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.

-- 
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: Native go xmpp server ?

[ortuman]

Have you tried jackal XMPP server?

https://github.com/ortuman/jackal

Currently there are many features missing, but minimally functional. Take a 
look! :)

El martes, 10 de julio de 2012, 13:09:04 (UTC+2), Max escribió:
>
> I searched for native go xmpp server and have not found one except 
> http://gitorious.org/go-xmpp that is not native
> Is Go a good candidate for language to implement xmpp server?
> I know erlang and nodejs are used in most popular xmpp servers now
> It is good application to compare languages in real world tasks that 
> require high concurrency.

-- 
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: Native go xmpp server ?

[ortuman]

I’ve just finished a first release of an XMPP server in Go.
https://github.com/ortuman/jackal 
There are many things to be implemented yet, but as a start point should work. 
;)

-- 
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] Why does the parallel version of a program runs slower?

[Tashi Lu]

Hi all,

As a newbie I tried to implement a simple program calculating the Catalan 
numbers, which are the numbers satisfying the recursion equation c(1) = 1; 
c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n).

At first, I implemented it without channels:
package main

import (
"fmt"
"os"
"strconv"
)

func catalan(n int) int {
if n == 1 {
return 1
}
res := 0
for i := 1; i < n; i++ {
res += catalan(n - i) * catalan(i)
}
return res
}

func main() {
n, _ := strconv.Atoi(os.Args[1])
for i := 1; i <= n; i++ {
fmt.Println(catalan(i))
}
}


Then I thought the calculation can be easily made concurrent, so I wrote 
the version below:
package main

import (
"fmt"
"os"
"strconv"
)

func catalan(n int, ch chan int) {
if n == 1 {
ch <- 1
return
}
res := 0
for i := 1; i < n; i++ {
ch1 := make(chan int)
ch2 := make(chan int)
go catalan(n - i, ch1)
go catalan(i, ch2)
res += <-ch1 * <-ch2
close(ch1)
close(ch2)
}
ch <- res
}

func main() {
n, _ := strconv.Atoi(os.Args[1])
for i := 1; i <= n; i++ {
q := make(chan int)
go catalan(i, q)
fmt.Println(<-q)
close(q)
}
}


But I found the second version was unexpectly slower than the first:
go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total
vs
go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 total

What's the reason behind this? How can I improve this concurrent version to 
make it faster?

-- 
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] sync.Cond implementation

[Jesper Louis Andersen]

There is a simple flowchart pertaining to data races:

First question: Does your program have a data race? If no, everything is
perfect. If yes, read on.
Second question: Does your program have a performance problem? If no, then
fix the race! If yes, then read on.
Third question: There is no third question, fix the race!

The best way to go at these kinds of problems is to make a concurrently
correct solution first, and then measure. Unless the penalty of locking is
severe to your platform, don't even worry about fixing stuff. If the
penalty of locking is too high, try to rethink your programs structure so
it avoids the locking first. Only then, when you don't have a good solution
without synchronization should you start looking at clever atomic update
solutions in my opinion. The reason is that they tend to hide errors and
they tend to be more brittle when moving to other architectures etc. So it
is usually a last-resort effort. Or, it is the case from here, where you
are carefully considering your options in the runtime because making things
faster at this level helps everyone write faster (and correct!) programs.

On Mon, Apr 16, 2018 at 3:00 PM  wrote:

> On Monday, April 16, 2018 at 7:08:27 AM UTC-4, Jesper Louis Andersen wrote:
>
>> On Sat, Apr 14, 2018 at 7:02 PM Penguin Enormous 
>> wrote:
>>
>>> But looking at your answer, I see that you may imply certain race
>>> conditions are allowed. Could you explain a bit more on that? Aren't race
>>> conditions supposedly bad?
>>>
>>> Race conditions can, in certain cases, be benign if guarded properly by
>> some other code. As long as you eventually solve the race in a valid way.
>>
>
> A little OT, but to avoid confusion for other readers, I want to point out
> that "logic race conditions" can be benign, but that "data race conditions"
> should never be considered benign *in user code*. By a "data race
> condition", I mean that two threads (or goroutines) are accessing the same
> data at the same time, and one of the accesses is a write.
>
> I am not trying to imply that Jesper was saying any different. I just
> wanted to clarify for others who could misinterpret his comments.
>
> --
> 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.
>

-- 
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] sync.Cond implementation

[jake6502]

On Monday, April 16, 2018 at 7:08:27 AM UTC-4, Jesper Louis Andersen wrote:
>
> On Sat, Apr 14, 2018 at 7:02 PM Penguin Enormous  > wrote:
>
>> But looking at your answer, I see that you may imply certain race 
>> conditions are allowed. Could you explain a bit more on that? Aren't race 
>> conditions supposedly bad?
>>
>> Race conditions can, in certain cases, be benign if guarded properly by 
> some other code. As long as you eventually solve the race in a valid way. 
>

A little OT, but to avoid confusion for other readers, I want to point out 
that "logic race conditions" can be benign, but that "data race conditions" 
should never be considered benign *in user code*. By a "data race 
condition", I mean that two threads (or goroutines) are accessing the same 
data at the same time, and one of the accesses is a write.

I am not trying to imply that Jesper was saying any different. I just 
wanted to clarify for others who could misinterpret his comments.

-- 
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] sync.Cond implementation

[Jesper Louis Andersen]

On Sat, Apr 14, 2018 at 7:02 PM Penguin Enormous 
wrote:

> But looking at your answer, I see that you may imply certain race
> conditions are allowed. Could you explain a bit more on that? Aren't race
> conditions supposedly bad?
>
>
Race conditions can, in certain cases, be benign if guarded properly by
some other code. As long as you eventually solve the race in a valid way.
This is of course somewhat brittle, so the usual recommendation is to avoid
these. However, in low-level runtime code inside a system, you can use
these quasi-races to speed up the code in certain situations.

In your example, we have another possible ordering which your code must
handle as well: suppose the atomic.Xadd(, 1) happens *after* the
signaler runs line 522. In this case, you are also blocked forever until we
signal again.

I think that if you want to prove the current model works, you need to take
sync.Cond.L (Locker) into account as well. The functions you mention
requires you to hold L on the waiter side when calling Wait(), and the
signaler needs to hold L as well at some point, though not necessarily when
calling Signal(). This is probably crucial in a proof of correctness on the
concurrency of said routine. Another important point is the relationship
between wait and notify, and the fact that each wait ticket is unique. This
establishes a kind of lemma on the ordering of wait and notify. Something
you can probably exploit in your full proof. 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.

-- 
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: Error running vgo with go1.10.1 on darwin

[jra]

You might be hitting the same problem 
as https://github.com/golang/go/issues/24694, which was fixed on April 5. 
Try updating your vgo (go get -u golang.org/x/vgo) and see if you get a 
different result.

The key thing is that vgo needs the GOROOT directory available to look at. 
It looks first in $VGOROOT, and then in $GOROOT, and then in the GOROOT 
compiled into the binary. If you have neither VGOROOT or GOROOT set, and 
the binary was built and then the GOROOT was moved, bad things will happen. 
But with commit 7373d8bcff7c682d097eabe987299681fa40a9cf, the error is more 
understandable.

 -jeff

>
>

-- 
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.