Question about features in next TBB release

[postaquestion]

Just wanted to know some information on whether the next major release of TBB would have a feature wherein you can assign priority to TBB task...??

[ARCH_R_Intel]

There is no plan to add any more priority support to TBB tasks in the next release. You can use task::add_to_depth() to exert some control.

The root problem is that a fundamental tenet of TBB (and OpenMP) is that parallelism should always be optional; there should alwaysbe a possible valid sequential execution. Letting task priorities be assigned seemslike a step in the direction of losingthis "relaxed sequential" model of parallelism and making parallelism mandatory. Mandatory parallelism introduces a lot of problems, including not having a sequential version to debug, and not being able to match potential parallelism to parallelism available in the hardware.

What kind of usage did you have in mind for priorities?

- Arch

[Shankar1]

Ya task::add_to_depth() andtask::set_depth() works fine to an extent when we prioritize the child tasks .But when it comes to cases where inwe submit roottasks which are in turnsplit (by using Parallel_for or so) and when we want toprioritize theexecution of the root tasksitseems quite difficultcurrently.

Say Isubmit 5 tasks(allocated using task::allocate_root)of whichtask1,task2 are of high priority and task3,task4,task5are of lower priority .I would atleast want task1 task2 to be started before the other tasks.But then this seems to be cannot be done with task::add_to_depth().

[ARCH_R_Intel]

Right, add to depth won't help you there because thieves steal the shallowest task, and the original thread works on the deepest tasks.

At a higher level, what sort of problem are you trying to solve by using priorities? We need to understand the higher-level intended purposes before pondering how to add priority control. My general take is that priorities cause as many problems as they solve (e.g. priority inversion, loss of relaxed sequential semantics).

[ralphsilberstein]

If I may suggest a case:

suppose I have a group of rendering and interpolation tasks which are well suited forTBB using parallelandpipeline and could conceivable operate within a range of priorities, but at a given time interval I have a hard-real-time task whichMUST IMMEDIATELYpreempt the rendering and interpolation tasks, terminate their progress,and then output some data. How could I achieve this with TBB?

Also, at the same time, suppose we have a dozen low priority tasks that do logging, maintainance, and routine communications, and we want them only to operate in spare time slices if and when the rendering and interpolation tasks are done. These low priority tasks could also use TBB as a group, but they should never preempt the rendering group tasks.

In these cases is seems that being able to assign priority ranges to a group of tasks would provide a solution, but I am unsure how this could be achieved with TBB as it is. Suggestions welcome.

[ARCH_R_Intel]

Hard real-time falls outside the "relaxed sequential" model of computation. I haven't seen any literature that addresses the marrying of work-stealing to prioritized tasks. So far, in our ponderings here, the most likely candidate is to have a separate TBB scheduler for each priority. But so far, we have not yet pursued implementation of this.

If the current TBB scheduler runs at the middle priority, you could run the high priority stuff and low priority stuff using explicit threads, with those thread's priorities set appropriately.

[akauppi]

How about just doing the hard realtime task as a separate OS level thread, where priorities do exist? TBB is intentionally designed to be usable side-by-side with other threading solutions.