task_scheduler_init quesiton

[bamboon]

Hi guys,

If I do initialize the thread scheduler with:

tbb::task_scheduler_init init(12);

Does the max_threads variable mean, how many threads there run in parallel at once or how many threads can be maximal spawned?

Consider for example the following,

void foo (...) {
...
tbb::parallel_invoke(foo(...), foo(...));
...
}

int main () {

tbb::task_scheduler_init init(8);

foo(...);
...
}


Will it spawn 8 threads at max and then no longer invoke any new foo()s in parallel but in serial, if it was like this:

void foo(...) {
...
foo(...);
foo(...);
...
}

or will the new threads just be spawned and set to sleep? I hope you guys can shed some light on this.

Thanks in advance.

[RafSchietekat]

In the example, 7 worker threads will quickly be lauched to assist the main thread, for a total of 8 threads (no more).

foo() will create more and more tasks and add them to the ready pools, where those 8 threads will find (locally, or stealing from another thread) and execute them. parallel_invoke does not have the oversight that would be needed to start executing serially, it just spawns tasks.

(Of course, foo() will spawn too many tasks, and the program will crash.)

[bamboon]

Ok, thank you very much.

Just to clarify your last statement, you mean it's gonna crash because I don't have a condition to stop recursion or because of a stackoverflow?

[SergeyKostrov]

Quoting bamboon

Ok, thank you very much.

Just to clarify your last statement, you mean it's gonna crash because I don't have a condition to stop recursion or because of a stackoverflow?

Yes, Itshould crash. Here are some test results I've done for different platforms:

...
//Evaluation of Max Number of Recursive calls
// These numbers could be different on another computer!
// Windows XP - DEBUG= 4774 RELEASE= 86172
// Windows XP with MinGW - DEBUG=130172 RELEASE=130172
// Pocket PC 2003 - DEBUG= 817 RELEASE= 1000
// Smartphone 2003 - DEBUG= 817 RELEASE= 1000
// Windows Mobile 5 - DEBUG= 817 RELEASE= 1000
// Windows XP with BCC - DEBUG= 64597 RELEASE= 64597
// Compact OS with TCC - DEBUG= 5898 RELEASE= 5898
// before the test application crashes
...

[RafSchietekat]

"Just to clarify your last statement, you mean it's gonna crash because I don't have a condition to stop recursion or because of a stackoverflow?"
One causes the other...

Admittedly I first thought of memory exhaustion, but I suppose the stack wiill overflow first, because there will only be about as many tasks in play as the stack is deep, and even with task_list that would be only by a constant factor more (correct me if I'm mistaken).

[SergeyKostrov]

Quoting Raf Schietekat

"Just to clarify your last statement, you mean it's gonna crash because I don't have a condition to stop
recursion or because of a stackoverflow?"

One causes the other...

Admittedly I first thought of memory exhaustion, but I suppose the stack wiil overflow first, because there will only be about as many tasks in play as the stack is deep, and even with task_list that would be only
by a constant factor more (correct me if I'm mistaken).

A "sad moment of crash" could be "delayed" if you change aLinker stack settings. For example, for a
Visual Studio and a Windows platform it could look like:

...
#pragma comment( linker, "/STACK:536870912,536870912" ) // 1GB in total
...

In that casean application with somerecursive processingcould work longer.