FAQ
So, trying to learn the nuances of Go concurrency by attacking the Dining
Philosophers problem.

Gist: https://gist.github.com/kid0m4n/6647055
You can directly run it here: http://play.golang.org/p/5VoUDSq54l

But to get a measure of speed, better to locally run it with a command line
like:

go run dining_gopher.go -count 10 -delay 10


This will utilize all cores on your machine and allow parallel "eating." I
was able to simulate a run with over 10000 philosophers and it was running
super fast (I didn't try and higher number.)

So:

    1. Is this solution valid?
    2. Obvious improvements?

Any all constructive comments are welcome.

Karan

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Michael Jones at Sep 21, 2013 at 3:11 pm
    Cute! Could be a sample program in the docs...

    On Sat, Sep 21, 2013 at 5:11 AM, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the Dining
    Philosophers problem.

    Gist: https://gist.github.**com/kid0m4n/6647055

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating." I
    was able to simulate a run with over 10000 philosophers and it was running
    super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at Sep 21, 2013 at 3:15 pm
    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. ;-)

    On Sat, Sep 21, 2013 at 4:10 PM, Michael Jones wrote:

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

    On Sat, Sep 21, 2013 at 5:11 AM, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the Dining
    Philosophers problem.

    Gist: https://gist.github.**com/kid0m4n/6647055

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 21, 2013 at 5:48 pm
    Oh yea, overlooked that... gophers >:)> 1 gopher
    On Saturday, September 21, 2013 8:45:00 PM UTC+5:30, Michael Jones wrote:

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


    On Sat, Sep 21, 2013 at 4:10 PM, Michael Jones <m...@google.com<javascript:>
    wrote:
    Cute! Could be a sample program in the docs...


    On Sat, Sep 21, 2013 at 5:11 AM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    So, trying to learn the nuances of Go concurrency by attacking the
    Dining Philosophers problem.

    Gist: https://gist.github.**com/kid0m4n/6647055

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan

    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Philippe Quesnel at Sep 23, 2013 at 1:17 am
    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
    On Sunday, 22 September 2013 19:28:09 UTC-4, Sonia Keys wrote:

    One problem is that it allows deadlocks. Run the program enough times and
    you'll see that once in a while it produces no output as each gopher grabs
    one fork and they all sit and wait for the timeout.
    On Saturday, September 21, 2013 12:11:01 AM UTC-4, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the Dining
    Philosophers problem.

    Gist: https://gist.github.com/kid0m4n/6647055
    You can directly run it here: http://play.golang.org/p/5VoUDSq54l

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Philippe Quesnel at Sep 23, 2013 at 1:28 am
    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
    On Sunday, 22 September 2013 21:17:49 UTC-4, philippe...@gmail.com wrote:

    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
    On Sunday, 22 September 2013 19:28:09 UTC-4, Sonia Keys wrote:

    One problem is that it allows deadlocks. Run the program enough times
    and you'll see that once in a while it produces no output as each gopher
    grabs one fork and they all sit and wait for the timeout.
    On Saturday, September 21, 2013 12:11:01 AM UTC-4, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the
    Dining Philosophers problem.

    Gist: https://gist.github.com/kid0m4n/6647055
    You can directly run it here: http://play.golang.org/p/5VoUDSq54l

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 23, 2013 at 5:10 am
    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:
    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
    On Sunday, 22 September 2013 19:28:09 UTC-4, Sonia Keys wrote:

    One problem is that it allows deadlocks. Run the program enough times
    and you'll see that once in a while it produces no output as each gopher
    grabs one fork and they all sit and wait for the timeout.
    On Saturday, September 21, 2013 12:11:01 AM UTC-4, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the
    Dining Philosophers problem.

    Gist: https://gist.github.com/kid0m4n/6647055
    You can directly run it here: http://play.golang.org/p/5VoUDSq54l

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Sep 23, 2013 at 1:49 am
    A more obvious problem is that gophers don't use cutlery. Instead they just
    mash their faces into the bowl.

    Andrew

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 23, 2013 at 5:10 am
    Heh... these be more civilized gophers
    On Monday, September 23, 2013 7:19:02 AM UTC+5:30, Andrew Gerrand wrote:

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

    Andrew
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at Sep 23, 2013 at 5:39 am
    I was sold when I saw the comment "Grabbed fork in left paw"

    On Sun, Sep 22, 2013 at 11:10 PM, Karan Misra wrote:

    Heh... these be more civilized gophers

    On Monday, September 23, 2013 7:19:02 AM UTC+5:30, Andrew Gerrand wrote:

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

    Andrew
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 23, 2013 at 5:05 am
    I am trying to reproduce that. But even with GOMAXPROCS=8, I cannot
    reproduce it. Anything which will show the problem more clearly.
    On Monday, September 23, 2013 4:58:09 AM UTC+5:30, Sonia Keys wrote:

    One problem is that it allows deadlocks. Run the program enough times and
    you'll see that once in a while it produces no output as each gopher grabs
    one fork and they all sit and wait for the timeout.
    On Saturday, September 21, 2013 12:11:01 AM UTC-4, Karan Misra wrote:

    So, trying to learn the nuances of Go concurrency by attacking the Dining
    Philosophers problem.

    Gist: https://gist.github.com/kid0m4n/6647055
    You can directly run it here: http://play.golang.org/p/5VoUDSq54l

    But to get a measure of speed, better to locally run it with a command
    line like:

    go run dining_gopher.go -count 10 -delay 10


    This will utilize all cores on your machine and allow parallel "eating."
    I was able to simulate a run with over 10000 philosophers and it was
    running super fast (I didn't try and higher number.)

    So:

    1. Is this solution valid?
    2. Obvious improvements?

    Any all constructive comments are welcome.

    Karan
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ibrahim M. Ghazal at Sep 23, 2013 at 8:03 am
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 23, 2013 at 9:46 am
    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
    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal wrote:

    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Philippe Quesnel at Sep 23, 2013 at 4:33 pm
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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
    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal wrote:

    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sonia Keys at Sep 23, 2013 at 7:43 pm
    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 !!
    >

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 24, 2013 at 1:46 am
    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:
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Philippe Quesnel at Sep 24, 2013 at 2:28 am
    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

    On Monday, 23 September 2013 21:45:56 UTC-4, Karan Misra wrote:

    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.comwrote:
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Юрий Соколов at Sep 24, 2013 at 10:26 am
    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 написал:
    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

    On Monday, 23 September 2013 21:45:56 UTC-4, Karan Misra wrote:

    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.comwrote:
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at Sep 24, 2013 at 11:07 am
    Yes.

    On Tue, Sep 24, 2013 at 4:26 AM, Юрий Соколов wrote:

    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 написал:
    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<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<https://www.youtube.com/watch?v=f6kdp27TYZs>

    On Monday, 23 September 2013 21:45:56 UTC-4, Karan Misra wrote:

    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.comwrote:
    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<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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

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

    How about this? https://gist.github.com/**kid0m4n/6647055<https://gist.github.com/kid0m4n/6647055>(
    http://play.golang.org/p/**Cy0ReZARbK<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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-**detector<http://blog.golang.org/race-detector>?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Karan Misra at Sep 24, 2013 at 11:19 am
    Not as per the Wiki page:

    Each philosopher must alternately think and eat. However, a philosopher can
    only eat spaghetti when he has both left and right forks. Each fork can be
    held by only one philosopher and so a philosopher can use the fork only if
    it's not being used by another philosopher. After he finishes eating, he
    needs to put down both forks so they become available to others. A
    philosopher can grab the fork on his right or the one on his left as they
    become available, but can't start eating before getting both of them.
    On Tuesday, September 24, 2013 3:56:03 PM UTC+5:30, Юрий Соколов wrote:

    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 написал:
    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

    On Monday, 23 September 2013 21:45:56 UTC-4, Karan Misra wrote:

    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.comwrote:
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Юрий Соколов at Sep 24, 2013 at 11:36 am
    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
    написал:
    Not as per the Wiki page:

    Each philosopher must alternately think and eat. However, a philosopher
    can only eat spaghetti when he has both left and right forks. Each fork can
    be held by only one philosopher and so a philosopher can use the fork only
    if it's not being used by another philosopher. After he finishes eating, he
    needs to put down both forks so they become available to others. A
    philosopher can grab the fork on his right or the one on his left as they
    become available, but can't start eating before getting both of them.
    On Tuesday, September 24, 2013 3:56:03 PM UTC+5:30, Юрий Соколов wrote:

    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 написал:
    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

    On Monday, 23 September 2013 21:45:56 UTC-4, Karan Misra wrote:

    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:
    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 !!

    On Monday, 23 September 2013 05:46:28 UTC-4, Karan Misra wrote:

    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

    On Monday, September 23, 2013 1:33:13 PM UTC+5:30, Ibrahim M. Ghazal
    wrote:
    Have you tried running it with the race detector:
    http://blog.golang.org/race-detector ?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 21, '13 at 4:39a
activeSep 24, '13 at 11:36a
posts21
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase