FAQ
I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
concurrency patterns" [2] last year. I was surprised to learn how strongly
Sutter warned against blocking. I have tried to understand why and tried to
discuss this in a new blog (that may be modified as the result of what kind
of feedback I see here). It's at
http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
(Disclaimer: my blogs are without any ads of any sort, no money involved,
and I am not affiliated with any of the parties)

Øyvind Teig
Trondheim, Norway

[1]
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

[2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.

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

  • Alexei Sholik at Jul 31, 2013 at 12:27 pm
    Hi,

    This is an interesting comparison and a very in-depth one. I haven't read
    all of it, but I noticed one thing that didn't seem right:

    One of the most successful models for providing high-level linguistic
    support for concurrency comes from Hoare’s Communicating Sequential
    Processes, or CSP. Occam and Erlang are two well known languages that stem
    from CSP.

    CSP and Actor model are two different models of concurrency, from what I
    can tell. Erlang clearly implements the Actor model, all message passing is
    asynchronous by default. I don't know much about occam, Wikipedia article
    says it implements CSP and block on every send and receive.

    You didn't compare Erlang to CSP directly, so I'm not saying your statement
    is incorrect, but I thought the distinction in communication semantics was
    worth pointing out.

    On Wed, Jul 31, 2013 at 1:24 PM, Øyvind Teig wrote:

    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.

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



    --
    Best regards
    Alexei Sholik

    --
    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.
  • Øyvind Teig at Jul 31, 2013 at 5:41 pm
    This is a quote from Go official documents, [17] in the blog.

    kl. 14:26:50 UTC+2 onsdag 31. juli 2013 skrev alco følgende:
    Hi,

    This is an interesting comparison and a very in-depth one. I haven't read
    all of it, but I noticed one thing that didn't seem right:

    One of the most successful models for providing high-level linguistic
    support for concurrency comes from Hoare’s Communicating Sequential
    Processes, or CSP. Occam and Erlang are two well known languages that stem
    from CSP.

    CSP and Actor model are two different models of concurrency, from what I
    can tell. Erlang clearly implements the Actor model, all message passing is
    asynchronous by default. I don't know much about occam, Wikipedia article
    says it implements CSP and block on every send and receive.

    You didn't compare Erlang to CSP directly, so I'm not saying your
    statement is incorrect, but I thought the distinction in communication
    semantics was worth pointing out.


    On Wed, Jul 31, 2013 at 1:24 PM, Øyvind Teig <oyvin...@teigfam.net<javascript:>
    wrote:
    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.

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



    --
    Best regards
    Alexei Sholik
    --
    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.
  • Mortdeus at Jul 31, 2013 at 1:01 pm
    1. How does your xchan proposal differ from the actor model. As far as I
    can tell by reading your proposal an xchan is an actor.

    2. Herb Sutter's opinion that ALL concurrent systems should be async is
    nonsense. I say that of course because go and plan9's thread model
    implements synchronous concurrency in a way that doesnt suck. The actor
    model has many setbacks of its own and by no means is an asynchronous
    system model guaranteed to produce a more efficient, responsive concurrent
    program than a program using a synchronous system model .

    3. The reality is that you have to design your program so that it
    effectively exploits the asynchronous nature of the actor model. Just like
    you have to design synchronous concurrent systems so there isn't heavy
    lock contention. Anytime we observe the efficiency of modern concurrent
    system or theoretical model, we always find that the most devastating
    deficiency in a concurrent system is the developer inability to designing a
    correct, efficient, simple, scalable system with the tools he is currently
    provided.

    Rob Pike in his talk "Concurrency isn't Parallelism" points this out by
    suggesting that the most fundamentally damning problem with concurrency is
    that we don't have an accurate understanding of what concurrency actually
    is in its fundamentally purest form. Rob suggests that the best way to
    understand concurrency is to view it as a foundational principle of
    software design; rather than a bunch of low level, complex, and
    exploitable features we can add-on to our program. (multiple cores, hyper
    threading, GPGPU, pthreads, actors, etc).

    Therefore taking our new understanding of concurrency into consideration,
    it should become obviously clear that "concurrency vs concurrency" is
    irrelevant because you wont learn anything useful when you compare a method
    against a mindset.
    On Wednesday, July 31, 2013 5:24:45 AM UTC-5, Øyvind Teig wrote:

    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Øyvind Teig at Jul 31, 2013 at 6:15 pm
    kl. 15:01:15 UTC+2 onsdag 31. juli 2013 skrev mortdeus følgende:
    1. How does your xchan proposal differ from the actor model. As far as I
    can tell by reading your proposal an xchan is an actor.

    I have from time to time tried to study the actor model. I have no
    experience with it and don't know it I must admit. I've been looking at
    Wikipedia now. I see that π-calculus has a relationship with the actor
    model and occam-π (oocam-pi) has π-calculus added to CSP. My paper about
    XCHAN from last years' CPA-2012 conference was peer reviewed by the core of
    the occam-π people. I can not remember or find in my own files any mention
    from them about XCHAN being an actor. There may have been some mention in
    the question session, but that is in case faint to me.

    The XCHAN is no own process, and cannot take primary initiative. It cannot
    spawn processes. It is a channel with an added feedback channel. And
    sending never blocks at link level etc. See in my blog and paper. If XCHAN
    is an actor it must be a tiny actor!

    I'd be glad for any one who has studied the XCHAN paper and is an actor
    expert to tell me. Maybe you?
    2. Herb Sutter's opinion that ALL concurrent systems should be async is
    nonsense. I say that of course because go and plan9's thread model
    implements synchronous concurrency in a way that doesnt suck. The actor
    model has many setbacks of its own and by no means is an asynchronous
    system model guaranteed to produce a more efficient, responsive concurrent
    program than a program using a synchronous system model .
    Sutter doesn't state that *all* should be asynchronous. Most may be seen as
    nonsense from some angle. But I must admit, I wouldn't have written the
    blog if I didn't wonder about his angle of view. And, totally blind as I
    may be, I don't see XCHAN having many setbacks..
    3. The reality is that you have to design your program so that it
    effectively exploits the asynchronous nature of the actor model. Just
    like you have to design synchronous concurrent systems so there isn't
    heavy lock contention. Anytime we observe the efficiency of modern
    concurrent system or theoretical model, we always find that the most
    devastating deficiency in a concurrent system is the developer inability to
    designing a correct, efficient, simple, scalable system with the tools he
    is currently provided.
    Yes, but in the direction from "difficult" to "concurrency is easy". With
    the occam version it is quite easy because the language is so simple.
    occam-pi is more complex. I have some Go code from golang-nuts in the XCHAN
    paper, and Go is more complex, *without* parallel usage rules. But it's
    still "easier than most" I believe.
    Rob Pike in his talk "Concurrency isn't Parallelism" points this out by
    suggesting that the most fundamentally damning problem with concurrency is
    that we don't have an accurate understanding of what concurrency actually
    is in its fundamentally purest form. Rob suggests that the best way to
    understand concurrency is to view it as a foundational principle of
    software design; rather than a bunch of low level, complex, and
    exploitable features we can add-on to our program. (multiple cores, hyper
    threading, GPGPU, pthreads, actors, etc).
    In occam, every statement/line is a process! You have to specify if they
    run SEQ or PAR. Taken from there I believe Rob Pike is right. But Go by
    design meets the wall, not with multicore with shared memory, but if memory
    is not shared. Not so for occam.
    Therefore taking our new understanding of concurrency into consideration,
    it should become obviously clear that "concurrency vs concurrency" is
    irrelevant because you wont learn anything useful when you compare a method
    against a mindset.
    I like it, even if I don't follow you fully. They both have dimensions of
    method and mindset. The C++ people do have a difficult job in trying to set
    up a concurrent mindset. People who will be going to use futures must of
    course also have a mindset. Even features need mindsets.
    On Wednesday, July 31, 2013 5:24:45 AM UTC-5, Øyvind Teig wrote:

    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Bryan Mills at Aug 1, 2013 at 9:40 pm
    Sutter has a decent point about futures being useful, but his extrapolation
    from "futures are useful" to "APIs should return futures instead of
    blocking" is utter nonsense.

    Only the caller knows whether the caller actually has useful work to switch
    to in the meantime. To take the example from Sutter's slide:

         auto result = async([=] { return f(x, y, z); });
         // ... code here runs concurrently with f...
         result.then([](int r) { go_and_use(r); });

    is equivalent to (and uses the same number of threads and context-switches
    as!):

         auto other_stuff = async([] {
           // ... code here runs concurrently with f...
         });
         go_and_use(f(x, y, z));
         other_stuff.wait();

    The latter version:
    * avoids needless copying (and thus needless pollution of data cache),
    * avoids needlessly transferring data between cores (a performance blunder
    that Sutter himself warns against in the discussion of read-write locks!)
    * has a more readable control flow, and
    * may occupy an additional thread stack while waiting for f() to return.

    The slide at 1:00:00 is telling: the "Done" operation, which happens after
    all of the "wait()" calls, occurs before the tasks are actually completed.
      That behavior is a very common class of _bug_ in aggressively asynchronous
    programs, and Sutter spends the entire rest of the talk describing a huge
    amount of boilerplate one can use to work around it.

    Why not avoid that bug in the first place by using a runtime with decently
    lightweight threads (i.e. goroutines) and moving the concurrency to the
    caller side?

    Leave internal concurrency in an API as the implementation detail it ought
    to be. Provide blocking APIs, and let your callers add asynchronicity
    explicitly _when they will actually benefit from it_.

    On Wednesday, July 31, 2013 6:24:45 AM UTC-4, Øyvind Teig wrote:

    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Øyvind Teig at Aug 2, 2013 at 2:19 pm
    The situation you describe here is very interesting. I assume that when a language does not have a concurrent process as first class citizen, spawning and joining may be difficult to get correct without deadlock etc. It's also about when to join, if the spawning process continues or blocks until all spawned processes have stopped, like occam does. Go often seems to wait for a (shared) join channel to simulate the same. The C++11 examples show that hidden solutions are difficult to discover, and must be learned, in the negative sense.

    --
    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.
  • Robert Johnstone at Aug 2, 2013 at 2:51 pm
    Your second bit is correct, only the caller knows whether there is work to
    be done in the meantime, but you've got the reasoning backwards. The API
    needs to accommodate clients that both do and do not have work to perform,
    so the safe option is to provide a future (or to provide both). The
    reasoning *may* be different between C/C++ and Go, since in Go it is
    relatively easy to wrap a synchronous call in a goroutine, but it would
    still be several lines to do properly. Finally, your concerns appear to be
    about micro-optimizations, which I doubt would be significant in the case
    of a blocking operation (i.e. waiting for some type of IO).

    On Thursday, 1 August 2013 17:40:43 UTC-4, Bryan Mills wrote:

    Sutter has a decent point about futures being useful, but his
    extrapolation from "futures are useful" to "APIs should return futures
    instead of blocking" is utter nonsense.

    Only the caller knows whether the caller actually has useful work to
    switch to in the meantime. To take the example from Sutter's slide:
    --
    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.
  • Bryan Mills at Aug 3, 2013 at 4:11 am
    My main concern is that blocking code is easier to read and understand than
    nonblocking code. Paying the complexity price of concurrency when it isn't
    useful obfuscates code for no real purpose.

    Nonblocking callers can easily spawn new futures as needed by making
    explicit "async" calls. But blocking callers can only synchronize if the
    asynchronous code properly plumbs through a joinable future or return
    channel - and, as Sutter's slides demonstrate, it's easy to implement that
    plumbing incorrectly.
      On Aug 2, 2013 10:51 AM, "Robert Johnstone" wrote:

    Your second bit is correct, only the caller knows whether there is work to
    be done in the meantime, but you've got the reasoning backwards. The API
    needs to accommodate clients that both do and do not have work to perform,
    so the safe option is to provide a future (or to provide both). The
    reasoning *may* be different between C/C++ and Go, since in Go it is
    relatively easy to wrap a synchronous call in a goroutine, but it would
    still be several lines to do properly. Finally, your concerns appear to be
    about micro-optimizations, which I doubt would be significant in the case
    of a blocking operation (i.e. waiting for some type of IO).

    On Thursday, 1 August 2013 17:40:43 UTC-4, Bryan Mills wrote:

    Sutter has a decent point about futures being useful, but his
    extrapolation from "futures are useful" to "APIs should return futures
    instead of blocking" is utter nonsense.

    Only the caller knows whether the caller actually has useful work to
    switch to in the meantime. To take the example from Sutter's slide:
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/Q8Mz2oR_UZQ/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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.
  • Adnaan badr at Aug 1, 2013 at 11:29 pm
    Parts of this article are good enough to be included in the go doc for
    better understanding of concurrency. Maybe a third/simpler perspective
    could have been discussed w.r.t Unix pipes. I think they represent the
    sender receiver model quite closely.
    On Wednesday, 31 July 2013 15:54:45 UTC+5:30, Øyvind Teig wrote:

    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Bienlein at Aug 2, 2013 at 8:38 am
    I don't know whether Rob Pike said this in the same presentation as
    mentioned here. But I listened to one where he says that race conditions
    and deadlocks happen much less when using chanels as opposed to mutexes,
    locks, or semaphores. I think this is the point. Channels are not a silver
    bullet with which you no longer run into deadlocks. Rather they are a means
    to get around mutexes, locks, or semaphores still being on the level of
    system programming.

    Actors are something you can implement with the use of channels and Go
    routines very easily. With actors you still have deadlock potential,
    though. Deadlocks can't happen because of locking since there aren't any
    locks, but deadlocks can happen in the message flow. The missing message
    problem is a famous one here and it is exactly the same problem as when a
    Go routine sits on a channel, because of an error in the logic some item
    does not get added to the channel.

    -- Bienlein

    Am Mittwoch, 31. Juli 2013 12:24:45 UTC+2 schrieb Øyvind Teig:
    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Luke Mauldin at Aug 2, 2013 at 11:16 am
    Can anyone link to a simple golang.org/play examples that illustrates the
    scenario Bienlein is describing?

    Luke
    On Friday, August 2, 2013 3:38:04 AM UTC-5, Bienlein wrote:

    I don't know whether Rob Pike said this in the same presentation as
    mentioned here. But I listened to one where he says that race conditions
    and deadlocks happen much less when using chanels as opposed to mutexes,
    locks, or semaphores. I think this is the point. Channels are not a silver
    bullet with which you no longer run into deadlocks. Rather they are a means
    to get around mutexes, locks, or semaphores still being on the level of
    system programming.

    Actors are something you can implement with the use of channels and Go
    routines very easily. With actors you still have deadlock potential,
    though. Deadlocks can't happen because of locking since there aren't any
    locks, but deadlocks can happen in the message flow. The missing message
    problem is a famous one here and it is exactly the same problem as when a
    Go routine sits on a channel, because of an error in the logic some item
    does not get added to the channel.

    -- Bienlein

    Am Mittwoch, 31. Juli 2013 12:24:45 UTC+2 schrieb Øyvind Teig:
    I saw Herb Sutter's lecture "C++ Concurrency, 2012 State of the Art (and
    Standard)" at C++ and Beyond [1] - after having seen Rob Pike's lecture "Go
    concurrency patterns" [2] last year. I was surprised to learn how strongly
    Sutter warned against blocking. I have tried to understand why and tried to
    discuss this in a new blog (that may be modified as the result of what kind
    of feedback I see here). It's at
    http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/.
    (Disclaimer: my blogs are without any ads of any sort, no money involved,
    and I am not affiliated with any of the parties)

    Øyvind Teig
    Trondheim, Norway

    [1]
    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism

    [2] http://www.youtube.com/watch?v=f6kdp27TYZs&sns=em.
    --
    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.
  • Jesse McNelis at Aug 2, 2013 at 11:38 am

    On Fri, Aug 2, 2013 at 9:16 PM, Luke Mauldin wrote:

    Can anyone link to a simple golang.org/play examples that illustrates the
    scenario Bienlein is describing?

    http://play.golang.org/p/FJtnEmg8jn
    In this case the function exits early due to detecting an error and never
    sends a value to the channel so the program deadlocks.


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

    --
    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.
  • Øyvind Teig at Aug 2, 2013 at 4:51 pm
    Concurrency means potential deadlock. Channels (zero buffered or n-dim buffered), asynchronous systems (with infinite buffer size) may deadlock. The first could be seen at link level, the last at application level. Any type of conversation could potentially deadlock when a chain of dependency ends up waiting for each other. It simply means that the parties will freeze, and over some time other parts dependent on a deadlocked group will also deadlock, and the whole sea freezes. The deadlock could, in a large system sit there for years because their service was not requested. There is no "race conditions and deadlocks happen much less when using channels as opposed to mutexes, locks, or semaphores" with adjectives like 'much' and 'less' - if it means that you can take it more or less easy. Learn deadlock free patterns like [1]. Learn to see roles like master and slave, client and server. And the server for some could itself be a client using other servers. A process could be a server for a set of clients and that pattern could be deadlock-free, provided the interprocess protocol is 100% adhered to. If a server shall always respond, with values or error, it cannot, because of some if-then-else "forget" to respond as promised. When you then discover that some very seldom times a server does not respond (and you should log it as an error to be fixed) and you "solve" it as a client by either wait for the response or time out - the timeout may (or will) get you in deep shit. This is thinking that's ok and even appropriate at lower OSI levels to do protocol layering between machines, but could cause a plane to crash if used between processes. What will happen if the server sends a response just after the client timed out, and the client wants a new service from the same client? Understand these scenarios. Draw process data flow diagrams and learn to discover cycles. Model your implementation and learn Promela and use Spin to see if there is any deadlock there. Have a look at LTSA or PAT tools. Aliasing may be wanted (double linked lists), but deadlock is never wanted. Channels will in no way be "better" than mutexes since there is no compare operator between them. It's not even certain which is the "highest" abstraction level. But channels may deadlock, so you must learn to use them. Don't blame the channels if you deadlock. That would be as wrong as blaming the number 4 for representing four of something. If you don't take this seriously you may in a year become frustrated with channels that seemed to work fine when you "tested" but then still deadlocked afterwards. "But didn't you TEST?" That's deadlocks for you, they often don't shown up before you are in or on the air. I think channels are good tools for building concurrent systems. I have used them for 25 years and have only used mutexes or critical sections or locks when I did not have channels.

    One more thing. Go channels and occam channels have somewhat different semantics. The languages are different implementations of CSP (when it comes to concurrency), so their fault scenarios would differ. But they would agree on deadlock. Beware.

    [1] Knock-come when both need to start an initiative: http://oyvteig.blogspot.dk/2009/03/009-knock-come-deadlock-free-pattern.html

    --
    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
postedJul 31, '13 at 10:24a
activeAug 3, '13 at 4:11a
posts14
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase