Google IO - Advanced Concurrency (nitpicking / philosophical question)

[Péter Szilágyi]

Hi,

  The following will be nitpicking, but still, I'm curious :)

  Just for the reference if somebody didn't see it I'm talking about this video, in particular, this code segment. The goal here was to make sure that all go-routines attached to an entity terminate before Close finishes, a concept that can be nicely verified by doing a forced stack unwind (i.e. panic) after close.

  Whilst this is nice indeed, there's one tiny race condition :P, after you send the error/nil into the errc channel, both threads are allowed to proceed. One racing to terminate, the other to dump the stack, thus sometimes you'll get a clean stack and sometimes the "killed" thread will still linger not having been scheduled.

  So, is there a way to really wait till all "requested" threads really terminate? I'm guessing not, but it's a nice philosophical question :)

Cheers,

  Peter

[Péter Szilágyi]

And here's the code to go with it ;)

http://play.golang.org/p/Ott0OlIsHT

You'll see that when the program panics, the "victim" is still alive :)...

[Péter Szilágyi]

To answer myself, this (i.e. non blocking errc) somewhat alleviates the issue, but I'm still not satisfied :D

[Jan Mercl]

On Sun, May 19, 2013 at 1:18 PM, Péter Szilágyi <pet...@gmail.com> wrote:

> Whilst this is nice indeed, there's one tiny race condition

I don't have time ATM to watch the talk nor to check your code, but
let me ask firstly: can you prove the by you mentioned race condition
using the race detector built into the Go 1.1 go tool?

-j

[Péter Szilágyi]

The -race checks for data races only. This is not a data race.

[Jan Mercl]

On Sun, May 19, 2013 at 1:54 PM, Péter Szilágyi <pet...@gmail.com> wrote:
> The -race checks for data races only. This is not a data race.

What is the "other" race condition wrt to 'data race'?

-j

[Péter Szilágyi]

Ok, you could call it a data race, but the data is the output of the stack dump, which is probably not something checked by -race :P

[Dan Kortschak]

Running this with GOMAXPROCS > 1 demonstrates the race. It's contrived.

http://play.golang.org/p/3R51ptBH5O

[speter]

  So, is there a way to really wait till all "requested" threads really terminate? I'm guessing not, but it's a nice philosophical question :)

Your guess seems correct (I am assuming that by threads you meant goroutines): "The exit of a goroutine is not guaranteed to happen before any event in the program." http://golang.org/ref/mem#tmp_5

(Another) Peter

[Sameer Ajmani]

Good question. You are correct that the goroutine that sends on the channel is still running when the send completed, so a stack trace may show it, which is a weakness in the technique. A sorry sleep at the end of a program would clear out such goroutines, but to my knowledge there's no precise solution, other than to ask the ringtone for the number of goroutines or parse the stack traces :-)

More generally there's room for more and better tools here.

--
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/groups/opt_out.
 
 

[Péter Szilágyi]

Nonetheless as I said earlier, this is rather nitpicking. Congrats on the great talk :)

[Jesse McNelis]

On Sun, May 19, 2013 at 9:18 PM, Péter Szilágyi <pet...@gmail.com> wrote:

  So, is there a way to really wait till all "requested" threads really terminate? I'm guessing not, but it's a nice philosophical question :)

To do this you'd need a way to refer to a goroutine.

Go explicitly avoids this. 

--
=====================
http://jessta.id.au

[Dave Cheney]

One solution to this is to use a waitgroup,
http://talks.godoc.org/github.com/davecheney/gosf/5nines.slide#22

[David Symonds]

On Sun, May 19, 2013 at 7:25 PM, Dave Cheney <da...@cheney.net> wrote:

> One solution to this is to use a waitgroup,
> http://talks.godoc.org/github.com/davecheney/gosf/5nines.slide#22

That still doesn't guarantee that that goroutine actually finishes
though. It only guarantees it got to the "defer w.wg.Done()". The
distinction is usually academic, but it would matter if you strictly
care about the goroutines that are running.

(also, nice to see you fixed your race in that example!)