Threads and Its Types in Operating System
Threads and Its Types in Operating System
••
•
Thread is a single sequence stream within a process. Threads have same properties as of the
process so they are called as light weight processes. Threads are executed one after another
but gives the illusion as if they are executing in parallel. Each thread has different states.
Each thread has
1. A program counter
2. A register set
3. A stack space
Threads are not independent of each other as they share the code, data, OS resources etc.
• Both can be scheduled by the operating system: Both threads and processes can be
scheduled by the operating system to execute on the CPU. The operating system is
responsible for assigning CPU time to the threads and processes based on various
scheduling algorithms.
• Both have their own execution context: Each thread and process has its own
execution context, which includes its own register set, program counter, and stack.
This allows each thread or process to execute independently and make progress
without interfering with other threads or processes.
• Both can communicate with each other: Threads and processes can communicate
with each other using various inter-process communication (IPC) mechanisms
such as shared memory, message queues, and pipes. This allows threads and
processes to share data and coordinate their activities.
• Both can be preempted: Threads and processes can be preempted by the operating
system, which means that their execution can be interrupted at any time. This
allows the operating system to switch to another thread or process that needs to
execute.
• Both can be terminated: Threads and processes can be terminated by the operating
system or by other threads or processes. When a thread or process is terminated,
all of its resources, including its execution context, are freed up and made
available to other threads or processes.
Threading Issues:
1. The fork() and exec() System Calls: The semantics of the fork() and exec()
system calls change in a multithreaded program. If one thread in a program calls
fork(), does the new process duplicate all threads, or is the new process single-
threaded? Some UNIX systems have chosen to have two versions of fork(), one
that duplicates all threads and another that duplicates only the thread that invoked
the fork() system call. The exec() system , That is, if a thread invokes the exec()
system call, the program specified in the parameter to exec() will replace the
entire process—including all threads.
When a device raises an interrupt at the process, the processor first completes the execution of
an instruction. Then it loads the Program Counter (PC) with the address of the first instruction
of the ISR. Before loading the program counter with the address, the address of the interrupted
instruction is moved to a temporary location. Therefore, after handling the interrupt, the
processor can continue with the process.
While the processor is handling the interrupts, it must inform the device that its request has
been recognized to stop sending the interrupt request signal. Also, saving the registers so that
the interrupted process can be restored in the future increases the delay between the time an
interrupt is received and the start of the execution of the ISR. This is called Interrupt Latency
A single computer can perform only one computer instruction at a time. But, because it can
be interrupted, it can manage how programs or sets of instructions will be performed. This is
known as multitasking. It allows the user to do many different things simultaneously, and the
computer turns to manage the programs that the user starts. Of course, the computer operates
at speeds that make it seem like all user tasks are being performed simultaneously.
An operating system usually has some code that is called an interrupt handler. The interrupt
handler prioritizes the interrupts and saves them in a queue if more than one is waiting to be
handled. The operating system has another little program called a scheduler that figures out
which program to control next.
Types of Interrupt
Interrupt signals may be issued in response to hardware or software events. These are classified
as hardware interrupts or software interrupts, respectively.
1. Hardware Interrupts
A hardware interrupt is a condition related to the state of the hardware that may be signaled by
an external hardware device, e.g., an interrupt request (IRQ) line on a PC, or detected by
devices embedded in processor logic to communicate that the device needs attention from the
operating system. For example, pressing a keyboard key or moving a mouse triggers hardware
interrupts that cause the processor to read the keystroke or mouse position.
Hardware interrupts can arrive asynchronously for the processor clock and at any time during
instruction execution. Consequently, all hardware interrupt signals are conditioned by
synchronizing them to the processor clock and act only at instruction execution boundaries.
In many systems, each device is associated with a particular IRQ signal. This makes it possible
to quickly determine which hardware device is requesting service and expedite servicing of
that device.
On some older systems, all interrupts went to the same location, and the OS used specialized
instruction to determine the highest priority unmasked interrupt outstanding. On
contemporary systems, there is generally a distinct interrupt routine for each type of interrupt
or each interrupts source, often implemented as one or more interrupt vector tables. Hardware
interrupts are further classified into two types, such as:
o Spurious Interrupts:
A spurious interrupt is a hardware interrupt for which no source can be found. The term
phantom interrupt or ghost interrupt may also use to describe this phenomenon.
Spurious interrupts tend to be a problem with a wired-OR interrupt circuit attached to
a level-sensitive processor input. Such interrupts may be difficult to identify when a
system misbehaves.
In a wired-OR circuit, parasitic capacitance charging/discharging through the interrupt
line's bias resistor will cause a small delay before the processor recognizes that the
interrupt source has been cleared. If the interrupting device is cleared too late in the
interrupt service routine (ISR), there won't be enough time for the interrupt circuit to
return to the quiescent state before the current instance of the ISR terminates. The result
is the processor will think another interrupt is pending since the voltage at its interrupt
request input will be not high or low enough to establish an unambiguous internal logic
1 or logic 0. The apparent interrupt will have no identifiable source, and hence this is
called spurious.
A spurious interrupt may result in system deadlock or other undefined operation if the
ISR doesn't account for the possibility of such an interrupt occurring. As spurious
interrupts are mostly a problem with wired-OR interrupt circuits, good programming
practice in such systems is for the ISR to check all interrupt sources for activity and
take no action if none of the sources is interrupting.
2. Software Interrupts
The processor requests a software interrupt upon executing particular instructions or when
certain conditions are met. Every software interrupt signal is associated with a particular
interrupt handler.
A software interrupt may be intentionally caused by executing a special instruction that invokes
an interrupt when executed by design. Such instructions function similarly to subroutine calls
and are used for various purposes, such as requesting operating system services and interacting
with device drivers.
Software interrupts may also be unexpectedly triggered by program execution errors. These
interrupts are typically called traps or exceptions.
When more than one device raises an interrupt request signal, additional information is needed
to decide which device to consider first. The following methods are used to decide which device
to select first,
1. Polling
In polling, the first device encountered with the IRQ bit set is to be serviced
first, and appropriate ISR is called to service the same. It is easy to implement,
but a lot of time is wasted by interrogating the IRQ bit of all devices.
2. VECTORED INTERRUPTS
In vectored interrupts, a device requesting an interrupt identifies itself directly
by sending a special code to the processor over the bus. This enables the
processor to identify the device that generated the interrupt. The special code
can be the starting address of the ISR or where the ISR is located in memory
and is called the interrupt vector.
3. Interrupt Nesting
In this method, the I/O device is organized in a priority structure. Therefore,
an interrupt request from a higher priority device is recognized, whereas a
lower priority device is not. The processor accepts interrupts only from
devices/processes having priority more than it.
Processors priority is encoded in a few bits of PS (Process Status register), and
it can be changed by program instructions that write into the PS. The processor
is in supervised mode only while executing OS routines, and it switches to
user mode before executing application programs.
Interrupt Handling
We know that the instruction cycle consists of fetch, decode, execute and read/write functions.
After every instruction cycle, the processor will check for interrupts to be processed. If there is
no interrupt in the system, it will go for the next instruction cycle, given by the instruction
register. If there is an interrupt present, then it will trigger the interrupt handler. The handler
will stop the present instruction that is processing and save its configuration in a register and
load the program counter of the interrupt from a location given by the interrupt vector table.
After processing the interrupt by the processor, the interrupt handler will load the instruction
and its configuration from the saved register. The process will start its processing where it's
left. This saves the old instruction processing configuration, and loading the new interrupt
configuration is also called context switching. There are different types of interrupt handlers.
1. First Level Interrupt Handler (FLIH) is a hard interrupt handler or fast interrupt
handler. These interrupt handlers have more jitter while process execution, and they are
mainly maskable interrupts.
2. Second Level Interrupt Handler (SLIH) is a soft interrupt handler and slow interrupt
handler. These interrupt handlers have less jitter.