It can occur for example when Thread with high priority is making some blocking operation (such as I/O one). But it's not a gold rule because sometimes Thread with lower priority can be executed and with higher priority suspended. Normally Thread with higher priority will run in preference to lower priority. It's "almost" because Java offers only 10 priority levels (0-10, possibility to use constant priorities: MIN_PRIORITY, NORM_PRIORITY and MAX_PRIORITY ) and a lot of OS have more than that. Java Threads also have priority that almost match cleanly to OS threads priority. Under-the-hood it's OS thread scheduler which manages Java Threads and dispatches them to available CPU. Each time when a new Thread instance is created, new OS thread is launched and is reclaimed when it terminates. Thus, threads in Java are executed as OS native threads. By the past it was not true because of green threads. How do Java Threads rely on previously described concepts ? In fact, most of JVMs use OS thread scheduler to manage constructed threads. It can have place for example: when thread with higher priority consumes all resources, exclusively one thread is working on synchronized block not allowing other threads to do the same. In multithreading compution the problem called thread starvation occurs when 1 or more threads can't get access to resources and remain blocked. In the other side, putting time slice too big would transform this round robin scheduling to FIFO queue. So each replacement causes a context switch - if there are too many switches, it can really slow down the performances. It's replaced by the first task from the queue. If the task doesn't execute within this time, it's moved to the end of a queue with waiting tasks. CPU gives some amount of execution time for each task (about 10-100 milliseconds) called time slice (aka quantum). The protection is called time slicing and is the 2nd interesting concept brought by preemptive scheduler. It should mean that threads with low priority can be never executed, shouldn't it ? Yes, but scheduler has a protection against this behavior called thread starvation. In general threads have assigned an execution priority that suggests CPU to launch some of them prior to others. Context switch has an impact on execution time because it needs some time to make context operations on memory (saving stopped context, loading new one). In this process scheduler consists on saving the state of interrupted process and loading the state of launched process. It corresponds to the situation when scheduler stops executed task and triggers the execution of another task. Preemptive scheduler brings some other interesting concepts. The interruption has place with the intention to resume stopped task later. It's because currently executed task can be interrupted and replaced by other task being until now in idle state. preemptive scheduling: this strategy is more flexible than the previous one.non-preemptive scheduling: running task is executed till completion, as for example in the case of FIFO queue.
To stay simple we can assume the existence of 2 scheduling strategies:
The decision is made on several factors, depending on used method. They're manipulated by a thread scheduler that decides which thread is launched at given moment. Threads aren't executed without any logic. Thanks to it CPUs are able to execute different programs at the same time. of the separate unit of execution in OS) that can be executed in parallel with other subdivisions. Officially it's a subdivision of a process (i.e. Thread schedulerīefore going into details, let's define a thread.
The last part shows some exploited concepts (priorities, yielding) through test cases. The second part concerns Java and explains how Threads interact with OS threads. Its first part focuses on general computer science definitions.
0 kommentar(er)
