threads within threads
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!
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
--- In Boost-Users@yahoogroups.com, "William E. Kempf"
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
threads function objects are of the same type, but different from
parent function object type.
This compiles and runs, but takes time equivalent to the threads running sequencially on a single thread. CPU usage indicates
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
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
new the that both threads on threads
on.
-- William E. Kempf
William I was enquiring into whether or not there were any known issues in boost threads regarding (for example) scoping. I am aware of basic thread theory, and yes, I do have a multiple CPU machine. It looks like I am hitting some system resource bottleneck, most likely memory speed/bandwidth. My intention was not to come across as an idiot so I could waste your time, I was merely trying to be polite. Don't worry about it, I'm sure boost threads are working fine.
pmedrow said:
William
I was enquiring into whether or not there were any known issues in boost threads regarding (for example) scoping. I am aware of basic thread theory, and yes, I do have a multiple CPU machine. It looks like I am hitting some system resource bottleneck, most likely memory speed/bandwidth. My intention was not to come across as an idiot so I could waste your time, I was merely trying to be polite. Don't worry about it, I'm sure boost threads are working fine.
Sorry, I did not intend for my reply to be perceived like this. It's a common mistake for people to assume that MT means faster applications, and since you didn't supply enough information about what your application did to determine if there was some design flaw in what you coded, I had to make an assumption. I'm not aware of any issues with the Boost.Threads design that would directly lead to what you observed. With out more information, and possibly even example code to illustrate it, I can't provide a better answer than what I have thus far. -- William E. Kempf
participants (2)
-
pmedrow -
William E. Kempf