Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
2464 Discussions

parallel_for called in non-main thread

tehhimora
Beginner
367 Views
Hello everybody,

Does tbb work when called from non-main thread ?

It is crashing all the time when calling parallel_for from non-main thread on Mac.

Thanks in advance
0 Kudos
10 Replies
Bartlomiej
New Contributor I
367 Views
Quoting - tehhimora
Hello everybody,

Does tbb work when called from non-main thread ?

It is crashing all the time when calling parallel_for from non-main thread on Mac.

Thanks in advance
Wait, wait, wait. ;-)
If you call it from another thread, it means you already have a ew threads, so you combine TBB with another threading technology.
The TBB Reference Manual describes mixing TBB with OpenMP (par. 8.2.6). Mixing with other technologies may or may not work, but in any case such combination does not seem like a good idea.
Why do you want to mix technologies like that? Obviously, there can be good reasons, but do you really have one?

0 Kudos
tehhimora
Beginner
367 Views
Quoting - bartlomiej
Wait, wait, wait. ;-)
If you call it from another thread, it means you already have a ew threads, so you combine TBB with another threading technology.
The TBB Reference Manual describes mixing TBB with OpenMP (par. 8.2.6). Mixing with other technologies may or may not work, but in any case such combination does not seem like a good idea.
Why do you want to mix technologies like that? Obviously, there can be good reasons, but do you really have one?


Thaks for reply.
The reason is very simple :)

TBB is used to parallelise huge computations and another threading technology is used to separate UI from huge computations :)
0 Kudos
Bartlomiej
New Contributor I
367 Views
Quoting - tehhimora

Thaks for reply.
The reason is very simple :)

TBB is used to parallelise huge computations and another threading technology is used to separate UI from huge computations :)
You keep being kryptic. ;-) What is this "another threading technology"?
Whatever the answer is, I thing TBB should be managable work fine, but it might require some tuning.. or luck. ;-)

0 Kudos
tehhimora
Beginner
367 Views
Quoting - bartlomiej
You keep being kryptic. ;-) What is this "another threading technology"?
Whatever the answer is, I thing TBB should be managable work fine, but it might require some tuning.. or luck. ;-)


"Another threading technology" is objective C's NSThread
0 Kudos
Bartlomiej
New Contributor I
367 Views
My guess is: you init the scheduler in a different thread than you do the parallel_for.
I'm not sure, but you probably do it and that's probably wrong. ;-)

In this case try one of the following:

i) init the scheduler each time before calling the parallel computations - a bit simpler to code, but wastes the processor time for creating/joining threads,
ii) make a dedicated thread that does the computations; it is statred once and waits blocked forcomputations requests.

I hope this will be helpful, otherwise we'll think more. ;-)

0 Kudos
Anton_Pegushin
New Contributor II
367 Views
Quoting - bartlomiej
My guess is: you init the scheduler in a different thread than you do the parallel_for.
I'm not sure, but you probably do it and that's probably wrong. ;-)

Hi, good chances are this is exactly the problem - TBB to-be main thread need to have the library initialized and you're not creating task_scheduler_init object on that separate thread before calling parallel_for.

Correction to the "overhead" claim. Thread pool will only be created once, so creating a second task_scheduler_init object will only cost you a check of whether the thread pool already exists.
0 Kudos
tehhimora
Beginner
367 Views
Quoting - bartlomiej
My guess is: you init the scheduler in a different thread than you do the parallel_for.
I'm not sure, but you probably do it and that's probably wrong. ;-)

Hi, good chances are this is exactly the problem - TBB to-be main thread need to have the library initialized and you're not creating task_scheduler_init object on that separate thread before calling parallel_for.

Correction to the "overhead" claim. Thread pool will only be created once, so creating a second task_scheduler_init object will only cost you a check of whether the thread pool already exists.

Thanks all for answering -
creating task_scheduler_init in the main thread was really the issue.
0 Kudos
RafSchietekat
Valued Contributor III
367 Views

You should have a task_scheduler_init in the main thread (for performance), but also in any other thread not created by TBB that wants to participate. These objects collaborate to keep the unique and reference-counted TBB scheduler in the air, so to speak, with high cost for the scheduler'sconstruction/destructionbut negligible cost for additional task_scheduler_init references.

High time for a FAQ entry...

0 Kudos
Alexey-Kukanov
Employee
367 Views
Quoting - Raf Schietekat

You should have a task_scheduler_init in the main thread (for performance), but also in any other thread not created by TBB that wants to participate. These objects collaborate to keep the unique and reference-counted TBB scheduler in the air, so to speak, with high cost for the scheduler'sconstruction/destructionbut negligible cost for additional task_scheduler_init references.

High time for a FAQ entry...


Or maybe not - just because we are about to release the version with automatic scheduler initialization on first use, which should eliminate most of the questions like this one. It may deserve its own FAQ entry though.
0 Kudos
RafSchietekat
Valued Contributor III
367 Views

"Or maybe not - just because we are about to release the version with automatic scheduler initialization on first use, which should eliminate most of the questions like this one. It may deserve its own FAQ entry though."
Maybe we could start a pool on how many times this question will still be asked until everybody is using a version with this change included. :-)

0 Kudos
Reply