Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
7 Views

parallel_for called in non-main thread

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
Highlighted
New Contributor I
7 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
Highlighted
Beginner
7 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
Highlighted
New Contributor I
7 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
Highlighted
Beginner
7 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
Highlighted
New Contributor I
7 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
Highlighted
New Contributor II
7 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
Highlighted
Beginner
7 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
Highlighted
Black Belt
7 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
Highlighted
7 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
Highlighted
Black Belt
7 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