Concurrency

Discussion in 'C++' started by David Rasmussen, Jan 21, 2004.

  1. Are there any indicators for

    1) whether the C++ commitee will include
    concurrency in the next standard
    2) what it will look like (Java, ZThreads, etc.)

    /David
     
    David Rasmussen, Jan 21, 2004
    #1
    1. Advertising

  2. On Wed, 21 Jan 2004 01:30:59 +0100, David Rasmussen <> wrote:

    >Are there any indicators for
    >
    >1) whether the C++ commitee will include
    >concurrency in the next standard
    >2) what it will look like (Java, ZThreads, etc.)


    Probably Boost Threads, if anything. Check out
    <url: http://www.boost.org/libs/thread/doc/index.html>.
    Alternatively pthreads.

    But I hope such support isn't added this time.

    Not having thread handling standardized reflects the situation that
    the standard library isn't designed for multithreading, that 'volatile'
    is next to unusable, and so on. In particular, there is the thorny
    issue of exceptions in threads. And the somewhat larger picture of
    exception importance levels, the next to unusable exception hierarchy,
    and handling of multiple exceptions and exceptions in destructors,
    which if addressed needs to be compatible and integrated with threads.
     
    Alf P. Steinbach, Jan 21, 2004
    #2
    1. Advertising

  3. David Rasmussen

    David Harmon Guest

    On Wed, 21 Jan 2004 01:30:59 +0100 in comp.lang.c++, David Rasmussen
    <> was alleged to have written:
    >Are there any indicators for
    >
    >1) whether the C++ commitee will include
    >concurrency in the next standard
    >2) what it will look like (Java, ZThreads, etc.)


    The newsgroup for the discussion of the C++ standardization process and
    what the C++ committee will do is comp.std.c++ (please read first before
    posting.)
    http://groups.google.com/groups?scoring=r&q=concurrency OR threads group:comp.std.c++
     
    David Harmon, Jan 21, 2004
    #3
  4. Alf P. Steinbach wrote:
    >
    > Probably Boost Threads, if anything. Check out
    > <url: http://www.boost.org/libs/thread/doc/index.html>.
    > Alternatively pthreads.
    >


    Pthreads? Surely, if anything, it will be an OOP
    approach.

    >
    > Not having thread handling standardized reflects the situation that
    > the standard library isn't designed for multithreading, that 'volatile'
    > is next to unusable, and so on.


    Still, many incarnations of the standard library
    exist that cope well with concurrency? It's not
    impossible.

    > In particular, there is the thorny
    > issue of exceptions in threads.


    It works reasonably well in Java, doesn't it?

    > And the somewhat larger picture of
    > exception importance levels, the next to unusable exception hierarchy,
    > and handling of multiple exceptions and exceptions in destructors,
    > which if addressed needs to be compatible and integrated with threads.
    >
    >


    I'm not sure these problems are greater than the
    problem of not having a standardized concurrency
    model in the language.

    But I see now that my discussion is off topic, so:
    sorry :)

    /David
     
    David Rasmussen, Jan 21, 2004
    #4
  5. David Rasmussen wrote:
    >
    > Alf P. Steinbach wrote:
    > >
    > > Probably Boost Threads, if anything. Check out
    > > <url: http://www.boost.org/libs/thread/doc/index.html>.
    > > Alternatively pthreads.
    > >

    >
    > Pthreads? Surely, if anything, it will be an OOP
    > approach.


    It will be both Boost.Thread-like stuff in <thread> and 100%
    pthreads compatible stuff in <cthread>. I bet a bottle of
    "Tisserand", Alf. ;-)

    >
    > >
    > > Not having thread handling standardized reflects the situation that
    > > the standard library isn't designed for multithreading, that 'volatile'
    > > is next to unusable, and so on.

    >
    > Still, many incarnations of the standard library
    > exist that cope well with concurrency? It's not
    > impossible.
    >
    > > In particular, there is the thorny
    > > issue of exceptions in threads.

    >
    > It works reasonably well in Java, doesn't it?


    Java's EH is totally brain-damaged.

    regards,
    alexander.
     
    Alexander Terekhov, Jan 21, 2004
    #5
  6. Alexander Terekhov wrote:
    >
    > Java's EH is totally brain-damaged.
    >


    Why?

    /David
     
    David Rasmussen, Jan 21, 2004
    #6
  7. David Rasmussen wrote:
    >
    > Alexander Terekhov wrote:
    > >
    > > Java's EH is totally brain-damaged.
    > >

    >
    > Why?


    Because you can't have throw() code in Java, to begin with.

    regards,
    alexander.
     
    Alexander Terekhov, Jan 21, 2004
    #7
  8. Alexander Terekhov wrote:
    >
    > Because you can't have throw() code in Java, to begin with.
    >


    I'm not sure I follow. A small example comparing
    C++ and Java, showing your point?

    /David
     
    David Rasmussen, Jan 21, 2004
    #8
  9. Alexander Terekhov, Jan 21, 2004
    #9
  10. Alexander Terekhov wrote:
    >
    > http://google.com/groups?selm=
    >
    >
    >>A small example ...

    >
    >
    > http://google.com/groups?selm=
    >


    None of these links meant anything to me. Maybe I
    lacked the context. But I'll take your word for
    it. All I know is that what little concurrent
    programming I did in Java with exceptions
    involved, worked flawlessly.

    /David
     
    David Rasmussen, Jan 21, 2004
    #10
  11. David Rasmussen wrote:
    [...]
    > None of these links meant anything to me. Maybe I
    > lacked the context. But I'll take your word for
    > it.


    Don't take my word. Click on "View: Complete Thread"
    and study the context.

    > All I know is that what little concurrent
    > programming I did in Java with exceptions
    > involved, worked flawlessly.


    Miracles Happen To Believers, you know.

    regards,
    alexander.
     
    Alexander Terekhov, Jan 22, 2004
    #11
  12. Alexander Terekhov wrote:
    > David Rasmussen wrote:
    > [...]
    >
    >>None of these links meant anything to me. Maybe I
    >>lacked the context. But I'll take your word for
    >>it.

    >
    > Don't take my word. Click on "View: Complete Thread"
    > and study the context.
    >


    Will do, when I get the time. But I really wish that a simple example
    could be given, not just an esoteric one.

    >
    > Miracles Happen To Believers, you know.
    >


    I am not a Java believer. I like C++ much more. But the few times I had
    to use Java and had to do something concurrently and with exceptions, I
    had met no limitations.

    /David
     
    David Rasmussen, Jan 22, 2004
    #12
  13. David Rasmussen

    Jorge Rivera Guest

    I did not find anything particularly useful in those links.

    Without pretending to understand every detail of that particular thread,
    I will give you my opinion...

    Unknown errors might happen at anytime. The fact that the documentation
    states that at any point in time the Java VM can crash does not imply
    that exceptions in threads is broken in Java and the VM is "brain-damaged".

    Think about what happens in any Unix environment when you get a SIGPIPE
    or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
    would prevent those errors, as they are outside the boundaries of the
    language, and the behavios of the process at that point is undefined.

    I think that in general, the Java thread and exception models are well
    designed and implemented.

    Jorge L

    Alexander Terekhov wrote:
    > David Rasmussen wrote:
    >
    >>Alexander Terekhov wrote:
    >>
    >>>Because you can't have throw() code in Java, to begin with.
    >>>

    >>
    >>I'm not sure I follow.

    >
    >
    > http://google.com/groups?selm=
    >
    >
    >>A small example ...

    >
    >
    > http://google.com/groups?selm=
    >
    > regards,
    > alexander.
     
    Jorge Rivera, Jan 23, 2004
    #13
  14. Jorge Rivera wrote:
    >
    > I think that in general, the Java thread and exception models are well
    > designed and implemented.
    >


    They are certainly better than not having a standard at all. And it is
    not like C++ is a perfect language which must not be befouled with
    unperfect things. C++ is full of ugly solutions, primarily stemming from
    C. I am not saying that we shouldn't care about the quality of the
    language, quite the opposite. But I don't see the harm (quite the
    opposite), in standardizing concurrency in some reasonable way. When we
    get more knowledge about the choices made, we can change the language
    later. That's how it is done now with other features. What separates
    concurrency from all the other half-hearted hybrid features of C++?

    /David
     
    David Rasmussen, Jan 23, 2004
    #14
  15. Jorge Rivera wrote:
    [...]
    > Think about what happens in any Unix environment when you get a SIGPIPE
    > or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
    > would prevent those errors, as they are outside the boundaries of the
    > language, and the behavios of the process at that point is undefined.


    The behavior of the PROCESS ta that point is fully defined in the
    "standard Unix environment" (which is nothing but extended ISO C
    environment). Some implementation even convert synchronous signals
    to implementation-defined exceptions (that's because the C++ std
    says that C++ "might not work" in signal handlers, I guess ;-) )
    and you can catch them using C++ catch(...). You might want to
    take a look at "is catch(...) safe" c.l.c++.mod thread.

    regards,
    alexander.
     
    Alexander Terekhov, Jan 23, 2004
    #15
  16. David Rasmussen

    Jerry Coffin Guest

    In article <4p0Qb.6805$>,
    says...
    > I did not find anything particularly useful in those links.


    That's what you should expect with Alexander -- he specializes in
    posting references that don't really refer to the question at hand. If
    you're willing to spend enough time chasing, you'll almost always find
    something relevant -- but it'll just be another instance of him making
    the same unsupported statement he's made in the current thread.

    The reality is that Alexander is a smart guy and he knows a lot about
    concurrent programming. Most of the statements he makes are correct,
    but his actual contribution to the average thread is a negative one --
    following the links he posts is normally just about the slowest, most
    inefficient possible way of learning anything (except that Alexander
    posts a LOT of stupid links, as if making the same unsupported assertion
    before acts as proof when he makes it again). You'd be more likely to
    learn something by choosing a book blindfolded, and then reading it in
    the hope that it might accidentally be related to something you care
    about.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Jan 23, 2004
    #16
  17. David Rasmussen

    Jorge Rivera Guest

    Jerry Coffin wrote:
    > In article <4p0Qb.6805$>,
    > says...
    >
    >>I did not find anything particularly useful in those links.

    >
    >
    > That's what you should expect with Alexander -- he specializes in
    > posting references that don't really refer to the question at hand. If
    > you're willing to spend enough time chasing, you'll almost always find
    > something relevant -- but it'll just be another instance of him making
    > the same unsupported statement he's made in the current thread.
    >
    > The reality is that Alexander is a smart guy and he knows a lot about
    > concurrent programming. Most of the statements he makes are correct,
    > but his actual contribution to the average thread is a negative one --
    > following the links he posts is normally just about the slowest, most
    > inefficient possible way of learning anything (except that Alexander
    > posts a LOT of stupid links, as if making the same unsupported assertion
    > before acts as proof when he makes it again). You'd be more likely to
    > learn something by choosing a book blindfolded, and then reading it in
    > the hope that it might accidentally be related to something you care
    > about.
    >

    Thanks for the insight... lol

    Jorge L
     
    Jorge Rivera, Jan 24, 2004
    #17
  18. David Rasmussen

    Jorge Rivera Guest

    Alexander Terekhov wrote:

    > Jorge Rivera wrote:
    > [...]
    >
    >>Think about what happens in any Unix environment when you get a SIGPIPE
    >>or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
    >>would prevent those errors, as they are outside the boundaries of the
    >>language, and the behavios of the process at that point is undefined.

    >
    >
    > The behavior of the PROCESS ta that point is fully defined in the
    > "standard Unix environment" (which is nothing but extended ISO C
    > environment). Some implementation even convert synchronous signals
    > to implementation-defined exceptions (that's because the C++ std
    > says that C++ "might not work" in signal handlers, I guess ;-) )
    > and you can catch them using C++ catch(...). You might want to
    > take a look at "is catch(...) safe" c.l.c++.mod thread.


    Thanks, I will verify that to understand better.

    However, the point I was trying to make is that there are system
    conditions in which *ANY* language might fail, regardless of code
    correctness and exception mechanisms, therefore I don't think that Java
    is particularly fickle because it could 'crash at any time'.

    Yes, the Java VM could fatally fail, and so could any mechanisms in the
    C++ language.

    >
    > regards,
    > alexander.
     
    Jorge Rivera, Jan 24, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Babu
    Replies:
    0
    Views:
    530
  2. Craig Deelsnyder

    Re: data concurrency

    Craig Deelsnyder, Aug 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    376
    Craig Deelsnyder
    Aug 29, 2003
  3. Brian Henry

    concurrency issues (on aspx page in vb)

    Brian Henry, Oct 8, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    388
  4. Homa
    Replies:
    7
    Views:
    461
    John Saunders
    Nov 16, 2003
  5. Homa
    Replies:
    1
    Views:
    481
    Alvin Bruney
    Nov 21, 2003
Loading...

Share This Page