Using task_arena with task_group_context

[Lucian_T_]

Hi

I have an old project that I want to slowly migrate towards using TBB. I want to use task_arena in my project so that I can manage how many threads I assign to different components.

There are some simple cases that I want to cover:

• enqueue tasks into different arenas
• dynamically change the priority of the tasks
• cancel tasks enqueued to the arenas

Looking at the task_arena interface, I can easily enqueue tasks into them (actually, enqueueing functors, not tbb::tasks). But I don't see any possiblity of assigning a task_group_context to the tasks that I enqueue.

The main documentation page (https://software.intel.com/en-us/node/506359) shows me how to associate the task with a task_group, but there is no way for getting the associated task_group_context from my task_group.

Is there a possibility to enqueue my tasks in a task_group_context that I specify?

Thank you very much,

LucTeo

[jimdempseyatthecove]

Explain what you intend to happen (or how you intend to use) by dynamically changing the priority of a task?

TBB does not (typically) oversubscribe the hardware threads. If a task is already running, changing the priority of the thread executing the task will not do anything with respect to the other threads (running tasks) of your application. It may however, affect the O/S process/thread scheduling with other processes.

If the task has been enqueued, but has not yet run, then I can potentially see some interest in reordering the task queue. Before we get too deep in this discussion, with TBB, you do not (typicall) launch a polling task that never terminates (at least until application exit) and then change its priority while it is running. If your intention is to raise the priority of the background task, then you've designed your application incorrectly with respect to TBB paradigm. What you can do, is at the point in your code that you desire to raise the priority, is to:

Simply call the task function (presumably thread safe). This has the initiating task incur the interruption.

YourDoItNowTask()
{
  static atomic<int> count = 0;
  if(count++ == 0)
  {
    for(;count--;)
    {
       // repeat until done
       ...
    }
  }
}

Enqueuing tasks elsewhere: You have to be careful when you do this. If your enqueue uses a lambda capture, then you must assure the lifetime of anything captured endures for the duration of the enqueued task. This means all referenced items... and the this object if one present.

Edit: As well as the lambda capture object itself.

Jim Dempsey

[Lucian_T_]

Hi Jim

Thank you very much for your response.

I have an application that loads a lot of data, processes the data, and then displaying the processed data to the user. Depending on the view the user is selecting we may need different data to be displayed, with different priority. For example, looking at the current view, the user may request/process data of types A, B and C, in this order. If the user selects another view, we may need to perform the tasks in another order: B, C and then A. For the purpose of this example, we will always have tasks of types A, B and C at a given time.

As being responsive is a major goal of the system, I would like to assign different priorities to different tasks, and then change the priority whenever the user is changing the viewport. The tasks that are enqueued in the system, and did not yet get the chance to execute, should be reprioritized.

I understand that the tasks that are currently executing will not changed, and this is ok with my application. The tasks are relatively small.

As discussed above, I need a task_arena to add these tasks into, as I have to partition my work between different areas.

Best regards,

LucTeo

[jimdempseyatthecove]

>>we will always have tasks of types A, B and C at a given time.

Do you mean to say that these are CPU bound tasks???
Or do you mean to say: At some display refresh interval, you want one of these tasks to refresh the display. (the next task is via your priority queue)

Jim Dempsey

[Lucian_T_]

Yes, they are CPU intensive tasks. And for the purpose of this example, I would always have n tasks of type A, m tasks of type B and k tasks of type C at any time enqued in my arena; n, m, k > 10 at any time.

Best regards,

LucTeo