Boost logo

Boost Users :

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-06-23 09:41:48


pmedrow said:
>
> Hi
> I am attempting to create a boost thread within an existing boost
> thread, i.e. a function called by the operator() function of an
> existing, running thread is attempting to make more threads. The new
> threads function objects are of the same type, but different from the
> parent function object type.
>
> This compiles and runs, but takes time equivalent to the threads
> running sequencially on a single thread. CPU usage indicates that both
> threads are running in parallel. Very strange...
>
> I am building with gcc v3.2.3 on red-hat linux build 2.4.20.
> Any ideas gratefully received!

You don't give anywhere near enough information for a definative answer,
but you've said enough for me to assume that you're under a misguided
assumption. Threads do not automatically equate into less overall clock
time. If you've got an MP machine and the scheduler runs the threads on
multiple CPUs, you can usually expect an increase in perceived speed. The
amount of time a thread spends waiting for something can also effect the
perceived speed. But the actual CPU time (as opposed to clock time) spent
is not effected by running multiple threads. If the threads just do a lot
of calculations with out doing any I/O and you run the program on a single
processor machine, you can expect no significant impact to the over all
time (actually, it will be a little slower due to the overhead of
creating/joining threads, and possibly due to time spent task switching,
but both should be too minimal to detect in most cases). Do know,
however, that turning a program into a multi-threaded program not only may
not give you a speed improvement, it may actually perform worse, due to
synchronization. It all depends on how the application is architected,
what the threads do, and how many CPUs are available to run the threads
on.

-- 
William E. Kempf

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net