Date: 2001-09-21 14:28:40
--- In boost_at_y..., maneshsankar_at_y... wrote:
> Hi Guys,
> I am a new bee to C++ but me keenly interested in getting a hold
> this, and I hop you guys wil help me out fast
> I have a major doubt about the Thread life cycle and resource
> consuming by threads..
> I have a situation in which I'll need to create a daemon thread
> which collects some system info and keeps calculating them. I have
> implement this either in C/C++ which ever is better in performance
> cause I am working in a critical module.
> and for your info, I am not allowed to touch MFC at all.. :(
> My Doubts..
> 1. Is C or C++ better in dealing with threads.. (remember, no MFC!)
Neither defines threads at all in their respective standards, so
technically neither can be better. However, most threading libraries
currently available that can be used by C or C++ are C libraries
making C the better language for this. Boost.Threads is trying to
address this, but not all issues have been fully addressed yet. So
the choice isn't an easy one. It will depend a lot of the platforms
you must run on, the compilers you'll use, how "simple" your threads
and synchronization needs will be, whether you'll have to rely on
certain differences between the abstract machines of C and C++, etc.
> 2. Is it better to create a thread and keep it idle as the whole
> module starts up so that when needed I can activate it? or is it
> better to create a new one as and when required? I am worried about
> the handling part and ofcourse the resource consumption
Thread creation is usually expensive in terms of cycles. This is why
thread pools are often used to increase performance. What you just
described is basically a pool of 1, and should provide better over
> 3. Is it better to put a free thread back to idle state till I
> it again or will it be better if I can kill it and proceed? Here
> again, I am worried about the handling part and ofcourse the
Basically, the last question provides the answer here.
> 4. Even if I get this thread done, can I easily port this from
> NT/2000 platforms to say LINUX and Solaris? What should i do to get
> that done?
No easy answer for you. I don't believe Solaris has a POSIX
implementation of threads, so there's not really a portable
solution. Boost.Threads will eventually port to Solaris, hopefully,
but since I can't do the port I can't tell you precisely when we'll
get this done.
Many of your questions are probably better asked on
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk