parallel_for called in non-main thread

[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

[Bartlomiej]

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?

[tehhimora]

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 :)

[Bartlomiej]

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. ;-)

[tehhimora]

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

[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. ;-)

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. ;-)

[Anton_Pegushin]

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.

[tehhimora]

Quoting - Anton Pegushin (Intel)

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.

[RafSchietekat]

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...

[Alexey-Kukanov]

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.

[RafSchietekat]

"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. :-)