Transcript Operating System Processes

Concurrent Servers
Process, fork & threads
ECE 297
ECE 297
Our transaction bracket
Repeat
get(table, key, &r)
Updates to r’s values based on application
logic
set(table, key, r)
Until No ERR_Transaction_ABORT
In the server
Updating versioned records in the server
• Receives a set(table, key, r) message
• Check r’s version against the version stored
• If there is a mismatch
– Return with Transaction Abort Error
• Otherwise
– Perform the update
• By incrementing the version & storing
– Return success
Our transaction bracket
Repeat
get(table, key, &r)
Updates to r’s values based on application
logic
set(table, key, r)
Until No ERR_Transaction_ABORT
Do you see a problem with this approach to process
transactions?
Problem
• After the get and before the set, the
application could accidentally modify the
version (or maliciously do so)
• Maybe update version to the version a
concurrent update sequence modifies the
version to
• Do you see a solution?
– This is something to discuss in your design
documents
Concurrent Servers
Process, fork & threads
ECE 297
ECE 297
Agenda
• Background on processes
• Creating processes (fork())
• Concurrent server with fork()
• Background on threads
• Concurrent servers with threads
ECE 297
Background on processes
ECE 297
Background
Process examples
•
•
•
•
•
•
•
•
Your browser
Your email reader
The shell your are working in
Compiler, debugger, Eclipse
Word
PowerPoint
Your application (i.e., test cases)
Your storage server, its client(s)
ECE 297
Background
Operating system process definitions
• A process is a program in execution
• A unit of execution characterized by
– A single, sequential thread of execution
– A current state (registers, program counter, …)
– An associated set of system resources (memory,
devices, files)
• A unit of resource ownership (more general)
• In the OS processes are identified with unique IDs
(process identifiers (PID))
• Sometimes also referred to as job, task, activity, …
ECE 297
Process structure
Background
A process consists of
ECE 297
stack
dynamic data
Memory
1. An executable (i.e., code)
2. Associated data needed by
the program (global data,
dynamic data, shared data)
3. Execution context (or state)
of the program, e.g.,
- Contents of data registers
- Program counter, stack
pointer
- Memory allocation
- Open file (file descriptors)
data
code
Background
Process context (state) & Process Control Block
•
•
•
•
•
•
Program counter
CPU registers
CPU scheduling information
Memory management information
Accounting information
I/O status information
OS manages
processes as queues
of PCBs
ECE 297
Background
Context switch
• CPU switching from one process to another process is
called a context switch.
• Execution state of running process has to be saved
and execution state of next process has to be
loaded (context is switched.).
• Time to save old and load new processes’ execution
state is called context-switch time.
• This time is overhead; The system does no useful
work while switching. Needs to be small.
• Time depends on hardware support.
ECE 297
Background
Concurrency
• Apparent, simultaneous execution of multiple
different processes in an interleaved fashion
• The context switching among processes creates
the illusion of processes running at the same time
• Given multiple cores or processors, processes
may truly run in parallel
ECE 297
Process creation
ECE 297
Process Creation
• Parent processes create child processes, which in turn
may create other child processes forming a tree of
processes in the system
– pid_t fork(void)
• Typically, child processes inherit parent’s resources
(code, address space, memory, file descriptors etc.)
– i.e., child is a duplicate of parent
• Sadly, but truly each child has one parent only, 
• Each parent may have many children
• If a parent dies, its children are inherited by the init
process (a process created by the OS shortly after boot)
ECE 297
A process
…
i = fork()
…
ECE 297
i = Process
ID of child
Parent process
Program
Counter
…
i = fork()
…
i=0
Child process
Program Counter
…
i = fork()
…
Parent and child are concurrently running processes
ECE 297
!
Concurrent server
ECE 297
listenfd = socket(AF_INET, SOCK_STREAM, 0)
…
bind(listenfd, …)
listen(listenfd, …)
Concurrent server
template
for( ; ; ){ …
connfd = accept(listenfd, …);
…
if ( (childPID = fork()) == 0 ){ // The Child!
close(listenfd);
// Close listening socket
do the work
// Process the request
exit(0);
}
…
close(connfd);
// Parent closes connfd
}
ECE 297
Parent process
if ( ( childPID = fork() ) == 0 ){
this code does not execute
}
Child process
if ( ( childPID = fork() ) == 0 ){
this code executes!
}
ECE 297
Status of client & server I
ECE 297
listenfd = socket(AF_INET, SOCK_STREAM, 0)
…
bind(listenfd, …)
listen(listenfd, …)
for( ; ; ){ …
connfd = accept(listenfd, …);
…
if ( (childPID = fork()) == 0 ){ // The Child!
close(listenfd);
// Close listening socket
do the work
// Process the request
exit(0);
}
…
close(connfd);
// Parent closes connfd
}
ECE 297
Status of client & server II
ECE 297
listenfd = socket(AF_INET, SOCK_STREAM, 0)
…
bind(listenfd, …)
listen(listenfd, …)
for( ; ; ){ …
connfd = accept(listenfd, …);
…
if ( (childPID = fork()) == 0 ){ // The Child!
close(listenfd);
// Close listening socket
do the work
// Process the request
exit(0);
}
…
close(connfd);
// Parent closes connfd
}
ECE 297
Status of client & server III
ECE 297
listenfd = socket(AF_INET, SOCK_STREAM, 0)
…
bind(listenfd, …)
listen(listenfd, …)
Concurrent server
template
for( ; ; ){ …
connfd = accept(listenfd, …);
…
if ( (childPID = fork()) == 0 ){// The Child!
close(listenfd);
//Close listening socket
do the work
//Process the request
exit(0);
}
…
close(connfd);
//Parent closes connfd
}
ECE 297
Concurrent server with fork()
• Basically, the template suffices to complete
Milestone 4’s concurrency requirement based on
process-based concurrent server
• Do consider caching and file access complications
• There are a few more complications
– Zombie children
– Signals
– Interrupted system calls (on some OSes)
ECE 297
Pros & cons of fork()-based design
• Handles multiple connections concurrently
• Clean sharing model
–File/socket descriptors are shared
–Global variables are not shared
• They are carbon copies!
• Simple and straightforward
ECE 297
Pros & cons of fork()-based design
• Non-trivial to share data between processes
•Requires inter-process communication
mechanisms (IPC)
•sockets
•shared memory
•semaphores
• Heavy overhead for process management (creation)
ECE 297