multithreading with each thread in a separate class instance vs. in aC-style kernel thread calls in

Discussion in 'C++' started by ssylee, Jan 28, 2008.

  1. ssylee

    ssylee Guest

    Other than looking cleaner in the object oriented approach (each
    thread's main function in one class) vs. having UINT _ _stdcall
    ChildThread (void *args) {...} required declarations for Windows
    kernel calls, I'm not sure about the advantages of the first method
    compared to the second method. I'm not sure if I have given enough
    information on what I'm confused on, but any enlightenment would be
    much appreciated. Thanks.
     
    ssylee, Jan 28, 2008
    #1
    1. Advertising

  2. Re: multithreading with each thread in a separate class instancevs. in a C-style kernel thread calls in C++

    ssylee wrote:
    > Other than looking cleaner in the object oriented approach (each
    > thread's main function in one class) vs. having UINT _ _stdcall
    > ChildThread (void *args) {...} required declarations for Windows
    > kernel calls, I'm not sure about the advantages of the first method
    > compared to the second method. I'm not sure if I have given enough
    > information on what I'm confused on, but any enlightenment would be
    > much appreciated. Thanks.


    Are you talking about detached threads vs a thread class ?

    If you are, my experience is that if you want a process to exit cleanly,
    it must close all it's threads before calling exit or returning from
    main. Then the question becomes, how do you reliably manage that. I
    have found that the "thread class" model where calling the destructor on
    a class as an implicit join is sufficient and succinct. There are other
    solutions as well but I think since threaded SW is harder to write,
    keeping the options simpler is better.

    That said, there are plenty of examples in the austria c++ unit tests of
    using threads as a class.

    http://austria.svn.sourceforge.net/...ia/test/tst_thread.cpp?revision=1&view=markup
     
    Gianni Mariani, Jan 28, 2008
    #2
    1. Advertising

  3. ssylee

    James Kanze Guest

    Re: multithreading with each thread in a separate class instance vs.in a C-style kernel thread calls in C++

    On Jan 28, 2:49 am, Gianni Mariani <> wrote:
    > ssylee wrote:
    > > Other than looking cleaner in the object oriented approach (each
    > > thread's main function in one class) vs. having UINT _ _stdcall
    > > ChildThread (void *args) {...} required declarations for Windows
    > > kernel calls, I'm not sure about the advantages of the first method
    > > compared to the second method. I'm not sure if I have given enough
    > > information on what I'm confused on, but any enlightenment would be
    > > much appreciated. Thanks.


    > Are you talking about detached threads vs a thread class ?


    > If you are, my experience is that if you want a process to
    > exit cleanly, it must close all it's threads before calling
    > exit or returning from main.


    At the very least, you must ensure that all threads are in a
    quiescent state, and will stay that way during shutdown. Having
    them all terminate, and joining them to ensure that they have,
    is certainly the surest solution, although there are others that
    can be made to work in practice.

    > Then the question becomes, how do you reliably manage that. I
    > have found that the "thread class" model where calling the
    > destructor on a class as an implicit join is sufficient and
    > succinct. There are other solutions as well but I think since
    > threaded SW is harder to write, keeping the options simpler is
    > better.


    In other words, you "detach" a thread by passing it off to a
    reaper thread which does the join, or something like that. That
    can be tricker than it sounds as well: if one of the detached
    threads runs for an exceedingly long time, and the reaper thread
    is joining on it, then the other "detached" threads won't be
    joined, and since they're not detached as far as the operating
    system goes, they will continue to use resources. In practice,
    I don't think that this is a problem very often, and in any
    specific program, it is easy to work around, but it does create
    a problem for a library solution.

    --
    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, Jan 28, 2008
    #3
    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. EvgueniB
    Replies:
    1
    Views:
    648
    Anthony Borla
    Dec 15, 2003
  2. Frank Fredstone
    Replies:
    1
    Views:
    452
    Jean-Francois Briere
    Jun 27, 2006
  3. yogesh
    Replies:
    3
    Views:
    592
    Kenny McCormack
    Feb 12, 2006
  4. Replies:
    3
    Views:
    178
  5. Lars Gierth
    Replies:
    6
    Views:
    227
    David Masover
    Mar 20, 2010
Loading...

Share This Page