Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

is TBB really non-preemptive?

gennadii_mog
Beginner
829 Views
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 :)
0 Kudos
5 Replies
pvonkaenel
New Contributor III
829 Views
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.
0 Kudos
jimdempseyatthecove
Honored Contributor III
829 Views

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


0 Kudos
gennadii_mog
Beginner
829 Views

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
0 Kudos
jimdempseyatthecove
Honored Contributor III
829 Views

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

0 Kudos
Bartlomiej
New Contributor I
829 Views
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.
0 Kudos
Reply