Re: To thread or not to thread ?
Sergey P. Derevyago wrote:
JohnQ wrote:
The point is that the "two different perspectives" above get
combined in one: divide the whole tasks into parallel jobs but
don't use a thread-per-job model.
Explain please how that solves any design problem/dilemma related to
choosing how many active threads are allowed per processor core.
It was stated that there are (only) two different perspectives on
multi-threaded programming:
1. Create N threads (as you have N CPUs on the board) and divide your
task into N parallel jobs.
2. Divide the task in as many parallel jobs as you can (say, M) and
create M threads to run them concurrently.
I just said that there is some more option to be considered: map
these M jobs
on your N CPUs. This is neither task-per-CPU nor thread-per-job
approach.
What does that mapping accomplish? I understood the difference
between those two perspectives as based on the fact that you either
already have the 'M' number, or deduce it based on the core count
(thus making it equal to the 'N'). If 'M' is governed by your tasks,
what would be the point of mapping them to cores, especially if the
numbers (N and M) are unrelated? Or are you proposing that all the
"tasks" that you have are [essentially] put in a queue of "tasks to
be parallelized" and then executed, N queue elements at a time? If
so, it looks like a combination of 2 and 1. Ok, maybe, it's 2, only
reiterated, refactored, by 1. Did I understand you correctly?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]