how do operate arenas in TBB?

[aurelieng]

Hello,

http://software.intel.com/en-us/blogs/2011/04/09/tbb-initialization-termination-and-resource-management-details-juicy-and-gory/

I'm trying to have several arenas in the same application, first question, is it possible?

Because, you talk about several threads which can each create an arena with a different number of worker, but how did you create them? (pthread, std::thread... i thought it was that)

I don't have an application in particular, but i try to understand the core of TBB.

[RafSchietekat]

It does not matter with what API you create the threads.

[aurelieng]

Ok, II tried with pthread, and it's work now.

So the only way to create several arenas is in creating threads, or there is another way for that ?

There is another example anywhere about it (as examples/task_priority/fractal) ?

[RafSchietekat]

"So the only way to create several arenas is in creating threads, or there is another way for that ?"
I don't understand the question: what would you want to do with a threadless arena (if it even makes sense)?

[Anton_M_Intel]

yes, it makes sense.. at least for some of our customers. Thus, we are working on adding explicit interface for managing arenas not necessarily connected to master threads. Stay tuned for arenas CPF in coming releases :)

[RafSchietekat]

How about a few hints already?

[Anton_M_Intel]

Ok, if you are interested.. Please say what do you think.

Motivation:

• Explicit concurrency level control that avoids known problems of task_scheduler_init.In particular, separation of global and local semantics.
• Explicit control over the arenas lifetime independent of application threads
• Enabling of architecture-aware applications, e.g. affinity, numa, etc
  • Explicit use of multiple arenas (perhaps hierarchically) to distribute work across HW
  • Enable better control of thread placement & data locality
  • Should allow work submission by different application threads

Main API

template void task_arena::enqueue(F)

Enqueues a task into the arena to process a functor, and immediately returns. Does not require the calling thread to join the arena

template void task_arena::execute(F)

Joins the arena and executes a functor, then returns to previous scheduler state. If not possible to join, wraps the functor into a task, enqueues it and waits for task completion. Further, it can decrement the arena demand for workers, causing a worker to leave and free a slot to the calling thread

task_scheduler_observer is extended for localsemanticscorrespondentlyto specified task_arena.

[RafSchietekat]

OK, looks interesting, no further comment at this time.

[jimdempseyatthecove]

>>Enqueues a task into the arena to process a functor, and immediately returns. Does not require the calling thread to join the arena

Using QuickThread you can do:

parallel_for(
ExcludeMyself$, // current thread does not participate
yourFunctor,
iYourBegin, iYourEnd // half open range
[,optionalArg [, arg[...]]]);
... continue immediately

Or

parallel_for(
&preDeterminedArenaControl, // current threadnot participate
yourFunctor,
iYourBegin, iYourEnd // half open range
[,optionalArg [, arg[...]]]);
... continue immediately
// optional
preDeterminedArenaControl.WaitTillDone();

The QuickThread implimentation is (currently)configured for SMP w/wo NUMA.

It is not clear as to if TBB will distribute (e.g. MPI, OpenCL, MIC), but the comment above seems to indicate this integration is planned. However, MPI (or OpenCL) should be integratable into current TBB without arena support.


Jim Dempsey