OpenMP threads similar to boost.Threads (or PThreads) for the OS p.o.v.?
christoph...@gmail.com
Do you know if OpenMP threads are considered equal as boost.Thread or
PThread ones by the OS?
For example if I launch an OpenMP calcul with 1 thread within a
boost.Thread (or PThread) thread, does the OS will see 2 threads?
Another example could be a main loop that is launching an OpenMP
calcul with 1 thread and in the meantime launches a Boost.Thread to do
something else. In that particular case, any idea of the thread
priority management? Can I set the OpenMP thread to have a higher or
lower priority than the boost.thread one?
I am a bit confused about OpenMP thread scheduling policy, thank you
for any help.
Bartlomiej Jacek Kubica
Hello,
On Tue, 10 Mar 2009, christoph...@gmail.com wrote:
> Do you know if OpenMP threads are considered equal as boost.Thread or
> PThread ones by the OS?
Yes, AFAIK, both Boost threads and OpenMP are just pthread* functions
wrapped up in sth. At least it's so in Linux - in Windows they're both
wrappings over windows threads API (probably).
> For example if I launch an OpenMP calcul with 1 thread within a
> boost.Thread (or PThread) thread, does the OS will see 2 threads?
Probably, yes. But in general it is a very bad idea to mix two
APIs/technologies like that unless you really have a reason and really
know what you're doing.
> Another example could be a main loop that is launching an OpenMP
> calcul with 1 thread and in the meantime launches a Boost.Thread to do
> something else.
Probably, yes, but - as above.
> In that particular case, any idea of the thread
> priority management? Can I set the OpenMP thread to have a higher or
> lower priority than the boost.thread one?
The idae of OpenMP is to give a rrlatively-high-level API. Becasue of that
it lacks some functionality of Pthreads, e.g. blocking with timeout,
condvars, etc. That's why I don't like OMP too much. ;-)
Even #pragma omp task (an analog of pthread_create is quite
a late addition. AFAIK there is no priority management.
> I am a bit confused about OpenMP thread scheduling policy, thank you
> for any help.
It seems to be OS-dependent. Moreover, if you have one thread pre
processor/core, scheduling policy is irrelevant, which is the most usual
case for parallel computing.
Best regards
Bartlomiej Kubica
David Schwartz
<bkub...@mion.elka.pw.edu.pl> wrote:
> It seems to be OS-dependent. Moreover, if you have one thread pre
> processor/core, scheduling policy is irrelevant, which is the most usual
> case for parallel computing.
But if you do that, and a thread blocks unexpectedly, you waste a
core. I think it's far more common to have "a few more" threads than
cores. That way if a small number of threads unexpectedly block, you
can still take advantage of all cores. Unless there's something badly
wrong with your platform, there should be no significant downside to
having a few extra threads.
DS
Bartlomiej Jacek Kubica
> On Mar 10, 5:54 am, Bartlomiej Jacek Kubica
> <bkub...@mion.elka.pw.edu.pl> wrote:
>
>> It seems to be OS-dependent. Moreover, if you have one thread pre
>> processor/core, scheduling policy is irrelevant, which is the most usual
>> case for parallel computing.
>
> But if you do that, and a thread blocks unexpectedly, you waste a
> core. I think it's far more common to have "a few more" threads than
> cores.
Yes, you're right probably.
But it's problem-dependent - in several problems (at least in numerical
computations - and that's my main area of interest) when a thread blocks
it means that there is not enough of some resource (work to do ?) or that
it has to wait for another threads - and if we had additional threads they
would block too.
> That way if a small number of threads unexpectedly block, you
> can still take advantage of all cores. Unless there's something badly
> wrong with your platform, there should be no significant downside to
> having a few extra threads.
Yes, if you mean a few than the penalty would be insignifficant.
The question is if there would be any benefit, which - in my opinion -
strongly depends on the solved problem.
Regards
Bartlomiej