Coder Perfect

Threads that are preemptive vs. threads that are not preemptive


Could someone kindly clarify the differences between the preemptive and non-preemptive threading models?

As per my understanding:

Can someone please:

Asked by Alok Save

Solution #1

Answered by Jerry Coffin

Solution #2

Cooperative threads are sometimes known as non-preemptive threads. POE is an example of this (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, like cooperative threads, can voluntarily give up the CPU, but if they don’t, it will be taken away from them, and the scheduler will start another thread. This includes POSIX and SysV threads.

Cooperative threads have several advantages, including increased efficiency (at least on single-core machines) and easier concurrency management: concurrency only arises when you yield control, therefore locking isn’t required.

Better fault tolerance is one of the main advantages of preemptive threads: a single thread failing to yield does not prevent all other threads from running. Multiple threads operate at the same time on multi-core devices, therefore it usually works better. Finally, you won’t have to be concerned about consistently conceding. Inside a large number crunching loop, for example, this can be really irritating.

Of course, you can combine them. Many cooperative threads can be found inside a single preemptive thread.

Answered by derobert

Solution #3

When using non-preemptive, this does not imply that the process does not execute context switching while waiting for I/O. According to the scheduling paradigm, the dispatcher will select a different process. We must have faith in the process.





Answered by pooria

Solution #4

Once a thread is handed control in a cooperative (non-preemptive) architecture, it continues to execute until it expressly surrender control or it blocks.

In a preemptive architecture, the virtual machine is free to intervene at any time and transfer control from one thread to another. Both models have their benefits and drawbacks.

Between priorities, Java threads are often preemptive. A thread with a higher priority takes precedence over one with a lower priority. A lower priority thread can run if a higher priority thread goes to sleep or blocks (assuming one is available and ready to run).

The higher priority thread, on the other hand, will interrupt the lower priority thread and run until it ends, blocks again, or is preempted by an even higher priority thread.

The Java Language Specification allows VMs to run lower priority threads instead of a runnable higher priority thread on rare occasions, but this is uncommon in reality.

The Java Language Specification, on the other hand, makes no mention of what should happen when equal priority threads are used. These threads will be time-sliced on some systems, with the runtime allocating a specific amount of time to each thread. The runtime preempts the running thread and switches to the next thread with the same priority when the timer expires.

A running thread will not be preempted in favor of a thread with the same priority on other systems. It will keep running until it either blocks, explicitly yields control, or is preempted by a thread with a higher priority.

When it comes to the benefits, both derobert and pooria have made a strong case for them.

Answered by Amimo Benja

Post is based on