Any idea when that feature is likely to make it into the commercial release?

Thanks

Mick

If you download the Reference Manual for the open source version from http://threadingbuildingblocks.org/documentation.php , and go to section 8.6, you'll find a description of task_scheduler_observer. It lets you define an object that gets notification when TBB creates or destroys a thread. If you create the object after TBB has already created a thread, you get notification before the thread does anything on behalf of the next parallel loop. Section 8.6.5 gives this guarantee in a somewhat oblique way.

If this solves your case, I'd like to hear about it, because we've been looking for example use cases for task_scheduler_observer.

Arch

Mick

While such a design wouldn't be as mighty and flexible as the one drafted above it might be easier to use - though duplicating the algorithm interfaces for it might be unpleasant.

Code example:

struct task {

void operator()(blocked_range& r, TS& thread_storage ) const {
// Use thread_storage to cache data that is only needed local to the thread calling this task.
// Thread affinity guarantees that the task isn't switched to another thread while running.
}

}; // struct task

TS thread_storage_prototype;
TSC thread_storage_container;

parallel_for( range, task( in, out ), thread_storage_prototype, thread_storage_container );

// Look into thread_storage_container and use whatever is stored in the contained thread storage objects.

Well, the longer I think about the aquire/release container the more I like the idea - mainly because it can be made to work correctly and if thread affinity comes into play it could be made very efficient without locking. Then it would also be easy to program a thread specific cache as described above but without the need for algorithm or task interface changes. I am looking forward to it ;-)

Cheers,
Bjoern

With the mine() kind of interface, core affinity does not work, because TBB has no control over when the OS switches a core from one thread to another. E.g., supposed threads A and B are both executing X=X+1 on core-local storage. We would not want to be in a situation where:

1. core 0 is running thread A
2. thread A is running X = X+1, but has only done the load so far
3. core 0 switches to thread B
4. thread B does X = X+1
5. core 0 switches to thread A
6. thread A does its store into X

The net effect would be X=X+1 instead of the intended X=X+2.

But with the acquire()/release() kind of interface, the notion of mapping to cores intriguing. Call it an "affinitized_bag". It would be a collection of T, initially empty. The acquire() operation would be guaranteed to return exclusive access to an object in the bag, and release() would release rights to it. Call the acquire/release pair an "access". Many conforming implementations would be possible:

• An implementation that has a single element, and serializes all accesses to it.
• An implementation that lazily creates an element per core, and serializes all accesses to the same element.
• An implementation that lazily creates an element per thread, and serializes all accesses to the same element.
• Any of the above, but changed to resolve conflicts by creating multiple elements instead of serializing.
• Random combinations of the above strategies, to shake loose programmer violations of the contract :-)

The big win from core affinity would be in situations where cache affinity is important. The neat part is that it would address cache affinity without handing programmers explicit core ids.

I think we should keep the idea of threads as far away from the user as possible. The beauty of TBB (in my mind) is the idea of "Task based programming" rather than "Thread based programming". If I'm understanding the mine() idea right, I think that would be the way to go. When writing a task, the programmer doesn't need know know anything about the thread it's running on. mine() just gets a pointer to the chunk of memory that belongs to the current thread that the task is running on and then afterwards you can iterate over all existing instances and pull out the data there.

Or would it make sense to go even one step lower and have a something like a ProcessorID or CoreID or something like that (like having the mine() idea work with a hash of ProcessorID rather than TreadID). Really, you're only ever going to have N threads running for N processors (cores), so you would only want to have N chunks local storage. So even if you have M>N threads, only N are going to be active at any time, so you just have the thread update the local storage that belongs on the processor it's running on. Wouldn't this eliminate the cache issues? May have to watch out for deadlocks.