is TBB really non-preemptive?

[gennadii_mog]

Hi all

I have a question that seems fundamental to me, but maybe i just lack a piece of knowledge. i read in several places (including bartlomiej's excellent paper, for example) that TBB uses a non-preemptive task scheduler.

and my question: how could that be? for all i know, operating systems does not offer the ability to keep your thread in memory - only for real time modes, for drivers and the like.

so my question is: does TBB really offer that, and if so, how does it do it?

thanks very much everyone :)

[pvonkaenel]

Quoting - gennadii.mog

Hi all

I have a question that seems fundamental to me, but maybe i just lack a piece of knowledge. i read in several places (including bartlomiej's excellent paper, for example) that TBB uses a non-preemptive task scheduler.

and my question: how could that be? for all i know, operating systems does not offer the ability to keep your thread in memory - only for real time modes, for drivers and the like.

so my question is: does TBB really offer that, and if so, how does it do it?

thanks very much everyone :)

If I understand correctly, the TBB scheduler really is a non-preemptive "task scheduler" such that it will not switch between incomplete tasks. However, the worker threads which TBB dishes the tasks out to are real OS threads which are preemptable.So you can consider there are two levels of scheduling: the low-level thread scheduling is preemptive and the high-level TBB tasks scheduling is non-preemptive.

[jimdempseyatthecove]

There is an additional quirk too. If you request a thread pool larger than number of available hardware threads (not generally recommended), the thread that the O/S chooses to prempt one of your TBB task pool threads may be another one of your TBB task pool threads.

Preemption is probably a poor choice of words since there is an implicit context for interpretation of what that means. And this context changes over time. On one extreme non-preemptible could be construed as the complete task (life of thread)is atomic. This is generally not the case. In prior (older) platforms, single processing systems, non-preemption meant that no other application could run for the duration of the non-preemption period, however the interrupt service could run, and even level-2 operating system functions (drivers)could run, but the scheduler was prohibited from context switching out the application. Preemption on multi-threaded platforms has a whole new set of sets ofmeanings.

Jim Dempsey

[gennadii_mog]

Quoting - jimdempseyatthecove

There is an additional quirk too. If you request a thread pool larger than number of available hardware threads (not generally recommended), the thread that the O/S chooses to prempt one of your TBB task pool threads may be another one of your TBB task pool threads.

Preemption is probably a poor choice of words since there is an implicit context for interpretation of what that means. And this context changes over time. On one extreme non-preemptible could be construed as the complete task (life of thread)is atomic. This is generally not the case. In prior (older) platforms, single processing systems, non-preemption meant that no other application could run for the duration of the non-preemption period, however the interrupt service could run, and even level-2 operating system functions (drivers)could run, but the scheduler was prohibited from context switching out the application. Preemption on multi-threaded platforms has a whole new set of sets ofmeanings.

Jim Dempsey

Thanks guys for these great answers. If I may ask:
1. if the scheduler has no-preemption policy to tasks, what happens when its thread is preempted (because of OS preemption)? I dont understand what does threading 'levels' mean. do we have here a context switcher implemented in software? even if so, I dont see what non-preemption mean - on any level...
2. if you could elaborate on the new set of meanings has 'Preemption' on multi-threaded platforms?

thanks again
Lior

[jimdempseyatthecove]

1. "The scheduler" has a definition dependent on a frame of reference.

TBB has a task scheduler that schedules tasks to threads under its control. TBB will not pre-empt its tasks once scheduled (excepting for canceling of tasks).

The operating system has a "The scheduler" that is free to preempt Processthreads.

On a system supporting Virtualization, the virtualization kernel has a "The scheduler" that is free to preempt Virtual Processors.

Where preemption means, interrupting the processor state, saving the context, doing other work, and restoring processor state. Saving and restoring a complete processor state has a significant amount of overhead.

There generally are consequences and/or side effects depending on what does the preemption and when the preemption occurs.

Should the TBB scheduler perform the pre-emption (which it does not) then there would be an unnecessary context switch since the currently running TBB thread has additional work to do. TBB is designed to run each task to completion or until that task requests intervention.

You cannot rely on the operating system or virtualization kernel to not pre-empt a thread within your application. What this means is your threads have the potential to be preempted while it is holding a lock (mutex) and this may have unintended (undesired) consequences. Therefore, if you can avoid a lock with additional programming then the effort may be worth while. When you cannot avoid a lock then reduce the time of holding the lock to as small as possible (thus reducing the probability of preemption while holding the lock).

2. these are old deffinitions of pre-emption for multi-threaded applications.

Jim Dempsey

[Bartlomiej]

1. if the scheduler has no-preemption policy to tasks, what happens when its thread is preempted (because of OS preemption)? I dont understand what does threading 'levels' mean. do we have here a context switcher implemented in software? even if so, I dont see what non-preemption mean - on any level...

The "server" thread gets preempted by some other thread - say a thread of another program, but when it gets back to being executed it executes the same task.

2. if you could elaborate on the new set of meanings has 'Preemption' on multi-threaded platforms?

It's just not to confuse what can be preempted and what can't and by what. ;-)
In TBB the tasks do not preempt each other, but the task-executing threads might get preempted by some other thread.

[Edit] I started writing my post before Jim Demspey has posted his. Now my post is a bit redundant, sorry.