Re: Threading in new C++ standard

Discussion in 'C++' started by James Kanze, Apr 16, 2008.

  1. James Kanze

    James Kanze Guest

    On Apr 16, 12:28 am, "Dann Corbit" <> wrote:
    > Rather than create a new way of doing things:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html
    > why not just pick up ACE into the existing
    > standard:http://www.cse.wustl.edu/~schmidt/ACE.html the same
    > way that the STL (and subsequently BOOST) have been subsumed?


    There are serious problems with the model ACE uses.

    > Since it already runs on zillions of platforms, they have
    > obviously worked most of the kinks out of the generalized
    > threading and processes idea (along with many other useful
    > abstractions).


    It's not actually used on "zillions of platforms"---as far as I
    know, it supports Windows and Unix, and that's about it.

    ACE is somewhat dated, and uses what was the classical model for
    thread objects at the time it was developed. The general
    concensus today is that this model isn't really that
    appropriate, at least for a language with value semantics like
    C++.

    The second aspect is that ACE (and Boost, which represents a
    more "state of the art" model) only address one of the reasons
    threading is desired, and don't effectively support uses like
    parallelizing, which are becoming important with the diffusion
    of multicore machines.

    > Even more interesting than generalized threading would be
    > generalized software transactions. The Intel compiler has an
    > experimental version that does
    > this:http://softwarecommunity.intel.com/articles/eng/1460.htm


    I think we're still largely at the beginning when it comes to
    knowing the best idioms to support threading. Rather than
    standardize something experimental, which later turns out to be
    far less than ideal, I think we should only standardize an
    essential minimum, on which people can build and experiment.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 16, 2008
    #1
    1. Advertising

  2. Hi James,

    >There are serious problems with the model ACE uses.


    ACE supports several threading models. Can you please elaborate on
    these problems?

    >> Since it already runs on zillions of platforms, they have
    >> obviously worked most of the kinks out of the generalized
    >> threading and processes idea (along with many other useful
    >> abstractions).

    >
    >It's not actually used on "zillions of platforms"---as far as I
    >know, it supports Windows and Unix, and that's about it.


    ACE has been ported to many more platforms than Windows and Unix,
    though not surprisingly those are the most common platforms on which
    it's used. Please see

    http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/ACE-INSTALL.html#platforms

    for more info on platforms that ACE has been ported to and the
    status of these ports. The status of the builds on the most commonly
    used platforms is available in real-time from

    http://www.dre.vanderbilt.edu/scoreboard/integrated.html

    Thanks,

    Doug
    --
    Dr. Douglas C. Schmidt Professor and Associate Chair
    Electrical Engineering and Computer Science TEL: (615) 343-8197
    Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
    Nashville, TN 37203 NET:
     
    Douglas C. Schmidt, Apr 16, 2008
    #2
    1. Advertising

  3. James Kanze

    Ke Jin Guest

    On Apr 16, 5:39 am, (Douglas C.
    Schmidt) wrote:
    > Hi James,
    >
    > >There are serious problems with the model ACE uses.

    >
    > ACE supports several threading models. Can you please elaborate on
    > these problems?
    >


    See http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

    Ke
     
    Ke Jin, Apr 16, 2008
    #3
  4. James Kanze

    James Kanze Guest

    On 16 avr, 14:39, (Douglas C.
    Schmidt) wrote:
    > Hi James,


    > >There are serious problems with the model ACE uses.


    > ACE supports several threading models. Can you please
    > elaborate on these problems?


    Or no model; like most other libraries, it's just a wrapper for
    whatever the implementation gives you.

    Seriously, what I was referring to was the fact that you have
    (or had, at least) a Thread class, from which the user had to
    derive. This was, of course, the accepted practice when ACE
    first appeared, but we've found better solutions since then.

    There's also the problem, IIRC, that there is no real
    distinction between detached threads and joinable threads. (Of
    course, ACE isn't alone in that:).)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 16, 2008
    #4
  5. Hi James,

    Thanks for providing some additional info.

    > Or no model; like most other libraries, it's just a wrapper for
    > whatever the implementation gives you.


    That's not entirely the case, e.g., the ACE_Thread_Manager is more
    than just a wrapper over the underlying implementation. Naturally, if
    the OS doesn't support threads at all it's hard for a library-based
    implementation to do much about this..

    > Seriously, what I was referring to was the fact that you have (or
    > had, at least) a Thread class, from which the user had to derive.


    I assume you're referring to ACE_Task here? It implements an Active
    Object model that's similar to Java's Thread class + a synchronized
    message queue.

    > This was, of course, the accepted practice when ACE first appeared,
    > but we've found better solutions since then.


    Can you please point to some descriptions of these solutions?

    > There's also the problem, IIRC, that there is no real distinction
    > between detached threads and joinable threads.


    It's not clear what you mean by this - can you please explain? The
    ACE_Thread_Manager implements both detached and joinable threads atop
    all the underlying operating systems, not just POSIX pthreads.

    Thanks,

    Doug
    --
    Dr. Douglas C. Schmidt Professor and Associate Chair
    Electrical Engineering and Computer Science TEL: (615) 343-8197
    Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
    Nashville, TN 37203 NET:
     
    Douglas C. Schmidt, Apr 17, 2008
    #5
  6. James Kanze

    James Kanze Guest

    On Apr 17, 9:25 pm, (Douglas C.
    Schmidt) wrote:
    > > Or no model; like most other libraries, it's just a wrapper for
    > > whatever the implementation gives you.


    > That's not entirely the case, e.g., the ACE_Thread_Manager is
    > more than just a wrapper over the underlying implementation.
    > Naturally, if the OS doesn't support threads at all it's hard
    > for a library-based implementation to do much about this..


    What I meant is that you don't really define when external
    synchronization is needed, and when it isn't. Under Posix,
    external synchronization is needed when Posix says it's needed,
    and under Windows, when Windows says it's needed.

    This is the aspect which really has to be treated at the
    language level: what does a "sequence point" mean in a
    multithreaded environment? There are also library aspects: when
    do I need external synchronization when using library components
    in two different threads.

    > > Seriously, what I was referring to was the fact that you
    > > have (or had, at least) a Thread class, from which the user
    > > had to derive.


    > I assume you're referring to ACE_Task here? It implements an
    > Active Object model that's similar to Java's Thread class + a
    > synchronized message queue.


    And Java's Thread class is an example of a poorly designed
    interface for threading. At least today; it was pretty much
    standard practice when it appeared, but we've learned a lot
    since then. And are still learning: I'm not sure that even
    today, threading technology is mature enough to be technically
    ready for standardization. (But politically, we don't have a
    choice. If the next version of the C++ standard doesn't address
    threading, the language is probably dead.)

    > > This was, of course, the accepted practice when ACE first
    > > appeared, but we've found better solutions since then.


    > Can you please point to some descriptions of these solutions?


    Boost offers parts of them. The whole concept of functional
    objects changes the situation considerably.

    IMHO, too, what I've learned from practical experience is that
    joinable threads and detached threads are two very different
    beasts. For detached threads, the best solution I've found so
    far is a template function, something more or less like:

    template< typedef Function >
    void
    startDetachedThread(
    Function f )
    {
    boost::thread( f ) ;
    }

    Fire and forget, in sum, with copy semantics handling all of the
    memory management issues.

    For joinable threads, you still want the thread class to take
    the functional object as an argument (so that you're ensured
    that it fully constructed before the thread starts). In Java,
    for example, deriving from java.lang.Thread is a common source
    of errors (which don't occur if you pass a Runnable to the
    constructor of Thread). In C++, the issue is further
    complicated by memory management issues, since there's no
    garbage collection. (I don't think that they're necessarily
    difficult issues, and I suspect that there are several
    acceptable solutions. But they do have to be addressed.)

    I'm not really too sure how ACE handles this; it's been a long
    time since I last looked at it (and it may have evolved since
    then).

    I'm also not too sure how (or if) ACE handles propagation of an
    exception accross a join. It's important that the standard
    offer some sort of support for this as well. Although I don't
    think it should be the default, and it doesn't bother me if it
    requires some programming effort to get, it is currently
    impossible to implement in Boost, and I suspect in any other
    threading system (since it also requires some language support,
    which isn't there at present).

    > > There's also the problem, IIRC, that there is no real
    > > distinction between detached threads and joinable threads.


    > It's not clear what you mean by this - can you please explain?
    > The ACE_Thread_Manager implements both detached and joinable
    > threads atop all the underlying operating systems, not just
    > POSIX pthreads.


    But do you even need a thread manager for detachable threads.

    Note that I'm talking here about the lowest level; the one which
    must be in the standard. There's definitely place for more
    elaborate (and less general) models at a higher level.

    With regards to standardization, what ACE has going for it, of
    course, is the fact that it probably has more users than all
    other systems combined, and we have a lot of concrete experience
    with it. What it has going against it is its age (it doesn't
    take into account all of the changes in programming style in the
    last years), and the fact that no one in the committee is
    championing it. (The Boost group are very active in
    standardization. You and others working on ACE don't seem to be
    so.)

    What all existing libraries have going against them (IMHO) is
    that the "existing practice" with regards to threads is that
    most multi-threaded programs don't actually work, or won't if
    the active thread changes at the wrong moment, of if they're
    ported to a multi-processor system, or if any one of a number of
    other things occur. From a technical point of view, this means
    that it's probably too early to standardize threading this go
    round. From a political point of view, however, I don't think
    we have a choice.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 18, 2008
    #6
    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. Ke Jin
    Replies:
    89
    Views:
    1,543
    red floyd
    May 23, 2008
  2. Szabolcs Ferenczi

    Re: Threading in new C++ standard

    Szabolcs Ferenczi, Apr 17, 2008, in forum: C++
    Replies:
    12
    Views:
    900
    Dmitriy V'jukov
    May 16, 2008
  3. Steven Woody
    Replies:
    0
    Views:
    425
    Steven Woody
    Jan 9, 2009
  4. Steven Woody
    Replies:
    0
    Views:
    458
    Steven Woody
    Jan 9, 2009
  5. jacob navia
    Replies:
    57
    Views:
    1,837
    Alexander Terekhov
    Aug 3, 2011
Loading...

Share This Page