Preemptive threads Vs Non Preemptive threads

Question

Can someone please explain the difference between preemptive Threading model and Non Preemptive threading model?

As per my understanding:

• Non Preemptive threading model: Once a thread is started it cannot be stopped or the control cannot be transferred to other threads until the thread has completed its task.
• Preemptive Threading Model: The runtime is allowed to step in and hand control from one thread to another at any time. Higher priority threads are given precedence over Lower priority threads.

Can someone please:

1. Explain if the understanding is correct.
2. Explain the advantages and disadvantages of both models.
3. An example of when to use what will be really helpful.
4. If i create a thread in Linux (system v or Pthread) without mentioning any options(are there any??) by default the threading model used is preemptive threading model?

Solution 1

1. No, your understanding isn't entirely correct. Non-preemptive (aka cooperative) threads typically manually yield control to let other threads run before they finish (though it is up to that thread to call yield() (or whatever) to make that happen.
2. Preempting threading is simpler. Cooperative threads have less overhead.
3. Normally use preemptive. If you find your design has a lot of thread-switching overhead, cooperative threads would be a possible optimization. In many (most?) situations, this will be a fairly large investment with minimal payoff though.
4. Yes, by default you'd get preemptive threading, though if you look around for the CThreads package, it supports cooperative threading. Few enough people (now) want cooperative threads that I'm not sure it's been updated within the last decade though...

Solution 2

Non-preemptive threads are also called cooperative threads. An example of these is POE (Perl). Another example is classic Mac OS (before OS X). Cooperative threads have exclusive use of the CPU until they give it up. The scheduler then picks another thread to run.

Preemptive threads can voluntarily give up the CPU just like cooperative ones, but when they don't, it will be taken from them, and the scheduler will start another thread. POSIX & SysV threads fall in this category.

Big advantages of cooperative threads are greater efficiency (on single-core machines, at least) and easier handling of concurrency: it only exists when you yield control, so locking isn't required.

Big advantages of preemptive threads are better fault tolerance: a single thread failing to yield doesn't stop all other threads from executing. Also normally works better on multi-core machines, since multiple threads execute at once. Finally, you don't have to worry about making sure you're constantly yielding. That can be really annoying inside, e.g., a heavy number crunching loop.

You can mix them, of course. A single preemptive thread can have many cooperative threads running inside it.

Solution 3

If you use non-preemptive it does not mean that process doesn't perform context switching when the process is waiting for I/O. The dispatcher will choose another process according to the scheduling model. We have to trust the process.

non-preemptive:

1. less context switching, less overhead that can be sensible in non-preemptive model

2. Easier to handle since it can be handled on a single-core processor

preemptive:

Advantage:

1. In this model, we have a priority that helps us to have more control over the running process

2. Better concurrency is a bounce

3. Handling system calls without blocking the entire system

Disadvantage:

1. Requires more complex algorithms for synchronization and critical section handling is inevitable.

2. The overhead that comes with it

Solution 4

In cooperative (non-preemptive) models, once a thread is given control it continues to run until it explicitly yields control or it blocks.

In a preemptive model, the virtual machine is allowed to step in and hand control from one thread to another at any time. Both models have their advantages and disadvantages.

Java threads are generally preemptive between priorities. A higher priority thread takes precedence over a lower priority thread. If a higher priority thread goes to sleep or blocks, then a lower priority thread can run (assuming one is available and ready to run).

However, as soon as the higher priority thread wakes up or unblocks, it will interrupt the lower priority thread and run until it finishes, blocks again, or is preempted by an even higher priority thread.

The Java Language Specification, occasionally allows the VMs to run lower priority threads instead of a runnable higher priority thread, but in practice this is unusual.

However, nothing in the Java Language Specification specifies what is supposed to happen with equal priority threads. On some systems these threads will be time-sliced and the runtime will allot a certain amount of time to a thread. When that time is up, the runtime preempts the running thread and switches to the next thread with the same priority.

On other systems, a running thread will not be preempted in favor of a thread with the same priority. It will continue to run until it blocks, explicitly yields control, or is preempted by a higher priority thread.

As for the advantages both derobert and pooria have highlighted them quite clearly.

View more solutions

Comments

[Zan Lynx]

Just a note about yield(): don't use it on Linux because it results in horrible performance. A yielded thread gets pushed to the very back of the thread schedule so the thread won't get scheduled until everything else in the entire system has had its chance.

[rakeshNS]

In my understanding when main process create two threads, they will execute in parallel. So does "Non Preemptive threading model" make the execution like, (finish_thread_1) -> (finish_thread_2) -> main()? I mean after thread 1 finished completely thread 2 will start then after completion, main() method will call. Is this correct? If so then what is the use of "Non Preemptive threads" ?

[Jerry Coffin]

@rakeshNS: non-preemptive (cooperative) threads mean that a thread runs until it calls some function that forces/allows a switch to another thread. In some cases, that's an explicit yield function. In others, allowing other threads to run is implicit in some other function(s). For example, in 16-bit Windows, when you called GetMessage, other threads/processes could run (they were considered processes, but they all shared one address space...)

[derobert]

@johnc I've rolled back your edit. "Exists" is intended there—concurrency (multiple threads running at once) exists only when you explicitly allow another thread to run by yielding. "Exits" doesn't make sense. I'm also not sure why you changed isn't to is not...

[johnc]

@derobet That's fine. It was a suggested edit that seemed to make sense at the time, though due to a typo in the suggestion, I re-editted it. At the time I associated the word 'yield' with the word 'exit' rather than 'exists'. To be honest, it was the typo; 'isn't -> is'n not' (or similar) that caused me to accept and edit the suggestion. I apologise that my obsession for correct spelling led me to mess up your answer

[Alexander Mills]

ummm preemptive threading is definitely more complex for the developer to handle, but perhaps simpler to implement? having trouble figuring out what you mean by "preemptive is simpler"?

[Jerry Coffin]

@AlexanderMills: I meant that preemptive threading is simpler to use. I stand by that. For one example, Microsoft added fibers to Windows NT 3.51.They were added primarily for internal use (e.g., in SQL Server) and they've long-since recommended against using them as a general rule. While there are designs (e.g., Goroutines) that aren't too terrible, they're still fairly problematic compared to full preemptive threading.