You are on page 1of 3

Kernel-Level Threads

As such, the OS now manages threads and processes. All thread operations are
implemented in the kernel and the OS schedules all threads in the system. OS
managed threads are called kernel-level threads or light weight processes.
In this method, the kernel knows about and manages the threads. No runtime
system is needed in this case. Instead of thread table in each process, the
kernel has a thread table that keeps track of all threads in the system. In
addition, the kernel also maintains the traditional process table to keep track
of processes. Operating Systems kernel provides system call to create and
manage threads.

User-Level Threads
However, for fine-grained concurrency, kernel-level threads still suffer from
too much overhead. Thread operations still require system calls.
Kernel-Level threads have to be general to support the needs of all
programmers, languages, runtimes, etc. For such fine grained concurrency we
need still "cheaper" threads.
To make threads cheap and fast, they need to be implemented at user level.
User-Level threads are managed entirely by the run-time system (user-level
library).The kernel knows nothing about user-level threads and manages them
as if they were single-threaded processes.User-Level threads are small and
fast, each thread is represented by a PC,register,stack, and small thread
control block. Creating a new thread, switiching between threads, and
synchronizing threads are done via procedure call. i.e no kernel involvement.
User-Level threads are hundred times faster than Kernel-Level threads.

Multithreaded Servers
The main purpose of multithreading is to provide simultaneous execution of two or
more parts of a program that can run concurrently.

Threads are independent. If an exception occurs in one thread, it doesn’t affect the
others.

Some multithreaded applications would be:


1. Web Browsers - A web browser can download any number of files and
web pages (multiple tabs) at the same time and still lets you continue
browsing. If a particular web page cannot be downloaded, that is not
going to stop the web browser from downloading other web pages.
2. Web Servers - A threaded web server handles each request with a new
thread. There is a thread pool and every time a new request comes in, it
is assigned to a thread from the thread pool.
3. Computer Games - You have various objects like cars, humans, birds
which are implemented as separate threads. Also playing the
background music at the same time as playing the game is an example
of multithreading.
4. Text Editors - When you are typing in an editor, spell-checking,
formatting of text and saving the text are done concurrently by multiple
threads. The same applies for Word processors also.
5. IDE - IDEs like Android Studio run multiple threads at the same time.
You can open multiple programs at the same time. It also gives
suggestions on the completion of a command which is a separate
thread.

Basic Multithreaded server

A multithreaded server is any server that has more than one thread. Because a
transport requires its own thread, multithreaded servers also have multiple
transports. The number of thread-transport pairs that a server contains defines the
number of requests that the server can handle in parallel. You create the first
transport within the task directly from the TServiceDefinition instance and clone
additional transports from this initial transport.

When a multithreaded server starts:

1. The first thread in the task starts up and creates


a TServiceDefinition using TStandardServiceDefinition.
2. This thread creates the first transport for the first dispatcher, directly or
indirectly.
3. The thread then creates more threads to receive multiple requests. Each
thread can only accommodate one transport; multiple threads cannot share
transports. You do not have to create
multiple MRemoteDispatcher instances; however, as you can
share MRemoteDispatcher instances between threads.
Instances that derive from MRemoteDispatcher and threads do not need to follow a
pre-set model. MRemoteDispatcher is extremely lightweight, so you can base your
model on the weight and semantics of the specific derivation
of MRemoteDispatcher that you intend to use.

Some possible implementations of multithreaded servers include:

 One instance of an MRemoteDispatcher for each thread-transport pair


 One instance of an MRemoteDispatcher for the entire server (where the
derivation provides its own synchronization for multithreaded access)

You might also like