[go-nuts] Dining Gophers!

Cute! Could be a sample program in the docs...

Minor point:

go run dining_gopher.go -count 10 -delay 10


should be

go run dining_gophers.go -count 10 -delay 10


I am seeing a great book cover image. ;-)

Oh yea, overlooked that... gophers >:)> 1 gopher

Hehe, great idea, I like it ;-)

There does seem to be some problems with this solution though.

When I run it with 1.1.2, I always get one single gopher eating at a time
and in increasing gopher# order:
1, then 2, then 3, 4, 5, ...

With 1.2rc1, the order is not 1,2,3,4,5 anymore, but I still get only one
gopher eating at a time !

looking-up the Dining Gophers, heuu, Philosophers on Wikipedia,
the shown example of a failing solution (deadlocks) looks *a lot* like what
we have here unfortunatly
http://en.wikipedia.org/wiki/Dining_philosophers_problem

Here is a modified version, tryong out the "Resource hierarchy solution".
(i.e the 1st suggested solution on wikipedia)
http://play.golang.org/p/ywiDs9WkWt
note:
1) I added some 'thinking' time after eating (algorithm does not seem to
work w/o it !! any ideas why !?)
2) removed the 'extra' goroutines
     for example, by using a buffered channel (len=1) we can directly 'feed
the spoon channel' (ouch, sorry about that one hihi)
3) I left the runtime.GOMAXPROCS code in, but I believe it is not necessary
(read here before that sometimes it can make code run slower)

what do you all think ?
I might look at the other suggested wikipedia solutions for fun

ps: I believe I know why the gopher needs some thinking time for the
algorithm to work :
without the call to time.Sleep() after putting down the fork, the gopher
just re-grabs the fork(s) right away,
so other gophers don't have much of a chance to grab the fork...

I would have expected that the runtime would switch to a goroutine that was
already waiting on
the channel when a value becomes available on it

Any run on play.golang.org is still not really concurrent, is it? Since
only one goroutine can execute at any point in time (even on 1.2rc1), we
are still talking about sequencing.

Therefore, if you run the origin solution on your local go installation
(where the runtime.GOMAXPROCS will take effect), you will actually see real
simultaneous eating. Infact, if you run it with high enough gopher count,
you will see the output messages being mangled as multiple "Gopher %v is
eating" start overlapping.

On Monday, September 23, 2013 6:47:49 AM UTC+5:30, philippe...@gmail.com
wrote:

A more obvious problem is that gophers don't use cutlery. Instead they just
mash their faces into the bowl.

Andrew

Heh... these be more civilized gophers

I was sold when I saw the comment "Grabbed fork in left paw"

I am trying to reproduce that. But even with GOMAXPROCS=8, I cannot
reproduce it. Anything which will show the problem more clearly.

Have you tried running it with the race detector:
http://blog.golang.org/race-detector ?

I dont think its really a problem of race. But yea, I did run it.

How about this? https://gist.github.com/kid0m4n/6647055
(http://play.golang.org/p/Cy0ReZARbK)

    1. I have used a 1 buffer chan int for simulating the secret tunnel
    between gophers. I was trying to avoid using buffered channels (as that is
    one extra thing people need to understand) but since it makes the solution
    much simpler, why not
    2. GOMAXPROCS is still required to simulate proper simultaneous eating
    with current design
    3. Rocky Balboa is standing in for the first gopher

In answer to your question / comment : I *was*/am running on my local
machine and getting only one gopher eating at a time !!?

With the version I tried out based on your example, modified to implement
the "Resource hierarchy solution",
it does run on the playground with the maximum of gophers eating at a time.
see here : http://play.golang.org/p/VfMAueqUOF

Note that it requires either a call to time.Sleep() after putting down the
forks,
or a call to runtime.Gosched() (to give other gophers a chance to grab the
fork)

Again, really a nice idea, I'm having fun with it, thx ;-)
Trying my hand at the "Chandy / Misra solution" now
Funny jokes too !!

There's a genre of problems like this, barbershop, santa, and so on. They
generally present some toy universe and invite you to use your knowledge of
real world physics (that two gophers cannot have their face in a bowl at
the same time, for example) to write the program that the problem poser was
thinking of (perhaps http://play.golang.org/p/M56fc8cgIy.) They're fun
exercises, especially if you don't take them too seriously.

On Monday, September 23, 2013 12:02:25 PM UTC-4, philippe...@gmail.com
wrote:
Funny jokes too !!
>

I am trying to extend the program so that it can output enough data for me
to then draw a proper resource utilization graph.

With GOMAXPROCS=1 and calling runtime.Gosched(), are we not still only
running a -> b -> c -> d, instead of any of them "together"

On Monday, September 23, 2013 9:32:25 PM UTC+5:30, philippe...@gmail.com
wrote:

you're correct ... they are not running in full *parallel*,

here's how I think it works (please, Go gurus, correct me, or add more
precise details ;-) ::
as soon as one gopher blocks on time.Sleep() (which simulates for example
some blocking / 'slow' I/O let's say),
then the go runtime tries to switch over to another goroutine.

So while gopher1 is 'eating' (sleeping !),
gopher3 is able to pick up forks and start eating .. sleeping,
with 5 gophers/forks there are no more possibilities, and we have the
maximum number of possible gophers eating 'at the same time'

Goroutines are .. well, goroutines, not threads !
I don't think we are garanteed that running 4 goroutines with gomaxprocs=4
(w. 4cpus) will necessarily give use four running threads !
Someone care to enlighten us here, please ? hehe Mr Pike ?

Time for me to go watch that "concurrency is not parallelism" talk / video
again ;-)
I strongly recommend it by the way, very interesting and well worth it IMHO
http://blog.golang.org/concurrency-is-not-parallelism

this one (even logner, +-50mins) also is very very nice :
https://www.youtube.com/watch?v=f6kdp27TYZs

Shouldn't gopher put back fork if it couldn't grab both forks at once?
For example:
http://play.golang.org/p/m5Eo5iviyb
or with timer instead of Gosched:
http://play.golang.org/p/g1k_j8ytpl

вторник, 24 сентября 2013 г., 6:28:25 UTC+4 пользователь
philippe...@gmail.com написал:

Yes.

Not as per the Wiki page:

Each philosopher must alternately think and eat. However, a philosopher can

Ok, they shouldn't. But they may, cause it is not prohibited.

By the way http://play.golang.org/p/VfMAueqUOF is not correct "Resource
hierarchy solution" - it uses a trick that goroutine is (more or less) not
preemptive.
If preemption added as in http://play.golang.org/p/29UbL1GhQ1 then deadlock
occures.
Error is in first gopher creation. Here is corrected version
http://play.golang.org/p/5oQ7yFHkvP


вторник, 24 сентября 2013 г., 15:19:43 UTC+4 пользователь Karan Misra
написал: