4. Drawbacks
1. This multiprocessing architecture is useful if the
handling of the client request takes some time or a
session state has to be kept by the (child) server
2. HTTP, however, is a stateless protocol. No session
information needs to be kept by the server
3. An HTTP server based on that architecture would be
inefficient
– The master server would have to create a process for each
HTTP connection, which would handle this one connection only
and then die
– While the master server creates a process it cannot accept
incoming requests – a bottleneck for the entire server.
5. Pre-Forking Model –
The leader-followers pattern
The preforking architecture
is based on a pool of tasks
(processes or threads)
which are playing 3 different
roles:
•wait for requests (listener)
•process a request (worker)
•queue in and wait to
become the listener (idle
worker)
•The listener is the leader,
the idle workers are the
followers
6. Win32/WinNt MPM
• Uses threads (a lot more performant than Win
processes)
– The number of threads is fixed, since idle threads impose almost
no performance issue
• There are two Windows processes in this
multitasking architecture:
– At restart, the master process creates the child process
– The worker process (child server process) contains the threads
which handle the requests,
– while the supervisor process (master process) makes sure that
the worker process works correctly
– For connection distribution to the workers a job queue is used
7. Win32/WinNt MPM cont.
• The master-child connection is done via
events
– master to child: shutdown, restart
– child to master: need restart, error that requires
shutdown
• Worker process’ threads:
– master thread – starts one or multiple listeners
– listener(s) thread(s) – accept requests and put into
the job queue
– worker threads – read from the queue and handle
requests (by calling some routine)
9. MPM for Linux/Unix
• Combine a multiprocessing and a
multithreading model:
– a variable number of processes, which include a
fixed number of threads
– pre-forking model on process level and job queue
model on thread level
– each child process incorporates a listener thread
• The master server creates the child
process, which starts a starter thread that
set up all worker threads and a single
listener thread
10. MPM for Linux/Unix cont.
• Within each child process, the
communication between the listener and all
worker threads is organized with two
queues:
– the job queue
– the idle queue
• Advantages of this approach are that it
combines:
– the stability of multiprocessing
– the high performance of multithreading
12. Thread Pool
1. Create a number of threads at process startup and
place them into a pool where they sit and wait for work.
• e.g. for multithreading a web server.
2. A thread from the pool is activated on the request, and
it returns to the pool on completion.
3. Benefits of thread pool:
– Faster service
– Limitation on the number of threads, according to the need.
4. Thread-pool-architecture allows dynamic adjustment
pool size.
13. Thread Pool Model for Ex4
• From the exercise definition:
Build a multithreaded server.
The main thread will handle user input,
second thread will handle load balancing
between computation threads, additional
three threads will be used to compute
prime numbers, and the last thread will
handle all output.
14. Thread Pool Model for Ex4
user
output thread
Main
thread
computation
thread
balancing
thread
input
computation
thread
computation
thread
15. thread creation
int pthread_create(pthread_t *thread, pthread_attr_t *attr,
void* (*start_routine)(void*), void *arg);
thread – pointer to the new thread
attr – the new thread attributes, usually NULL (i.e. system
thread that we can do ‘join’ on it = wait to his end).
start_routine – pointer to the function that is the thread
code, the return value of that function is the end value of
the thread
arg – parameter for the start_routine function
16. mutex locks
int pthread_mutex_lock(pthread_mutex_t *mutex);
– blocks until the mutex is free, and than locks it
int pthread_mutex_trylock(pthread_mutex_t *mutex);
– fails if the mutex is already locked, otherwise – locks it
int pthread_mutex_unlock(pthread_mutex_t *mutex);
– frees (unlocks) the mutex
17. Event-driven
• The main program creates acceptors.
• Each acceptor creates event-handler for
each event it is interested in, and the
handler registers for this event.
• The main program listens for events.
• When event occurs, the appropriate
acceptor is notified, notify the handler,
which handle the event.
18. Event-driven cont.
• Advantages:
– services can run independently
– integrating new services is easy
– a programmer can do his own ‘task management’ and
save context switching (context is saved in the data
structure)
• Drawbacks:
– resource management problems if requests arrive
faster than they are processed
– big overhead for system with short-duration services
– harder to implement than other models
