NETW 3005 Threads and Data Sharing. Reading For this lecture, you should have read Chapter 4 (Sections 1-4). NETW3005 (Operating Systems) Lecture 03 -

NETW 3005

Threads and

Data Sharing

Reading

• For this lecture, you should have read Chapter 4 (Sections 1-4).

NETW3005 (Operating Systems) Lecture 03 - Threads and data-sharing 2

Last Lecture

• Hierarchical structure in Operating Systems

• System calls and interrupts

• Representing processes in Operating Systems

• Overview of process scheduling


This lecture

• Cooperating processes.

• Communication between parent and child processes.

• Shared memory and pipes.

• Threads.

• Inter-process communication.


Independent and cooperating processes

• Independent processes. The execution of one process cannot affect the execution of another.

• Cooperating processes. The execution of one process can affect the execution of another.

• Naturally, any processes which share data are cooperating processes.


Advantages of process cooperation

• Information sharing. Two processes might want to access the same data.

• Computation speedup. To introduce some parallelism into program execution.

• Modularity. Having program functions performed by their own processes.

• Convenience. A user might want to print a file at the same time as editing it.


Communication between processes


root

child

daemon init

user1 user2 user3

system proc application

child

A process can create a child process to do a particular task. But to do so, it has to be able to communicate with its child.

Creating child process in UNIX (1)

• In UNIX, a child process is created with a system call called fork. fork creates a new process, consisting of a copy of the address space of the parent process.

• The child process then typically executes an execlp command, which loads a new program into its memory space (erasing the copy of the parent).


Creating child process in UNIX (2)

• System calls are functions, and functions can return values. fork is no exception.

• Both parent and child processes continue after the fork function call—but a different value is returned in the two cases:– the value for the child process is 0.– the value for the parent process is the PID of

the child.


Some questions (1)

• Why is the parent’s address space copied to the child process if execlp is just going to wipe it all out?


Some questions (1)

• Why is the parent’s address space copied to the child process if execlp is just going to wipe it all out?

• Because you want to be able to pass arbitrary values as the parameters of execlp.


Some questions (2)

• Why is the parent process given the PID of the child process?


Some questions (2)

• Why is the parent process given the PID of the child process?

• So it knows which process is going to deliver the results of the computation.


What next?

• As we have seen, the child process will go off and do its own thing, possibly executing a different program.

• The parent process often executes a wait system call, which moves it off the ready queue until the child process has terminated.

• When the child process has terminated, it may return data to the parent.


Process termination

• When a process has executed its last statement, it executes an exit system call. At this point:– it may return data to its parent process (the

one waiting for it to terminate);– all its resources (main memory, open files

etc.) are de-allocated by the operating system.


Process termination

• Processes can also die more violently – they can be terminated by other processes (e.g. in UNIX with kill).

• There is an important constraint on which processes you can kill — you can only kill your children.


Zombie process: a process whose parent has terminated.

Shared memory: a simple kind of data sharing

• The map memory family of system calls allow two processes to share some region of main memory.

• This is achieved by overriding the operating system’s normal constraints on memory access for processes.


Operating System

P2

P1

The Producer-Consumer problem

• A producer process writes data to a buffer of fixed size.

• A consumer process reads data from the buffer.

• The two processes are being scheduled independently by the CPU.


Obviously …

• The producer process must wait if the buffer gets full;

• The consumer process must wait if the buffer is empty.


This is a taster for the issue of process synchronisation.

Pipes (in UNIX)

• Pipes provide a simple method for sharing data.

• grep ‘party’ events.txt | lpr


What’s happening here?

• We’re typing the command to the shell.

• When you hit ‘return’, the shell process normally forks a child process, which is told to execute the specified program.

• When you link two programs with a pipe, the shell process first sets up a buffer in memory, then forks two child processes, which write to / read from this buffer.


Threads (1)

• Operating systems frequently support a special kind of process called a thread to allow more complex data-sharing.

• A standard process has a data section, code section, and a full PCB.

• A thread just has a program counter, a register set and a stack space.


Threads (2)

• You can have several threads within a single process, using the same code section, data section, memory and I/O resources.


Threads (3)


SPC R

SPC R

SPC R

code segment

data segment

OS management information

Terminology

• The code segment, data segment, and O/S housekeeping information of a process is collectively known as a task.

• A task with just one thread is called a heavyweight process.

• A thread is also known as a lightweight process.


Operations on threads

• Threads and processes can do a similar range of things. – A thread can wait while an I/O process

completes (called blocking). – A thread can be in different states – ready,

blocked, running, or terminated. – A thread can create child threads.


Advantages of threads (1)

• Responsiveness. Multithreading an interactive application may allow a program to continue running, even if part of it is waiting.

• Switching speed. Switching between threads is faster than between (heavyweight) processes, because there’s less to change.


Advantages of threads (2)

• Communication between processes. We don’t need special setups for shared memory when implementing communicating processes as threads in the same task.

• Redundancy avoidance. If you need several versions of one program reading the same data at the same time, it’s inefficient to have each version implemented as a heavyweight process.


Problems with threads

• It’s a bit perilous running threads, because there are no OS-enforced constraints on how threads can interact.

• However, if the code has been designed by a single person, there’s no reason why it can’t be written correctly.


Servers as threads (1)

• A web server is a process that provides data over the web to requesting clients. (Possibly a large number of them.)

• Imagine a queue of client requests arriving in an input buffer. If we implemented the web server as a single process, what would the problem be?



The file server would be inequitable. The clients at the end of the queue wouldn’t get ANY service until the ones on the front had been fully serviced.


• It’s more efficient if the web server process forks a child process to deal with each separate request that arrives.

• Why?



• It’s more efficient if the web server process forks a child process to deal with each separate request that arrives.

• Why? Because this way each client gets some access to the CPU, and gets some data delivered.



• One particular thread is a daemon – it does nothing but listen for new requests.

• Each time a new request is detected, a new thread is created to service this request.


User-level threads

• Implemented in user-level libraries, without the need for system calls.

• Fastest kind of thread to switch between.

• But, the kernel doesn’t know about individual threads within a process.


Why should that matter?

I. Unfairness. One process might have 100 threads, another process just one. The kernel gives them equal time in the CPU.

II. System calls. If a thread makes a system call, then the whole (heavy-weight) process is suspended until it’s completed; that includes all the other threads.


Kernel-level threads

• Implemented via system calls.

• In this case, the kernel knows about individual threads.

• But switching between threads is slower.


Multi-threading models (1)

• Many systems support both user-level and kernel-level threads.

• We then need some way to map user-level threads to kernel-level threads.



• In a many-to-one model, many user threads are mapped onto a single kernel thread.

• This suffers from the problem of blocking: the kernel doesn’t know about it when one thread blocks.



• In a one-to-one model, each user thread is mapped onto a single kernel thread.

• This doesn’t suffer from the above prob-lem, but there’s an overhead in creating the corresponding kernel threads.

• Most systems only support some maximum number of kernel threads.



• In a many-to-many model, a set of user threads is multiplexed onto a (smaller or equal) set of kernel threads.

• You need to have an extra mechanism that allocates each user thread to a kernel thread.

• A many-to-many scheme avoids many of the disadvantages of both above schemes.


Java threads (1)

• As well as any threads defined in a Java program, there are a number of extra threads running on behalf of the JVM.

• For instance:– a thread to listen and react to the

mouse/keyboard;– a thread to do garbage collection;– a thread to handle timer events (e.g. the sleep() method).


Java threads (2)

• The JVM will implement threads in different ways in different versions, and in different operating systems.


Message-passing systems (1)

• One final, general, way of communicating between processes is via a message-passing system.

• To pass messages between processes, a communication link must be established.


Message-passing systems (2)

• This can be implemented in various ways, but it must specify certain logical characteristics:– Can a link be associated with more than two

processes?– What is the capacity of the link?– Is the link unidirectional or bidirectional?

• The main instructions: send, receive.


Direct and indirect communication

• Direct communication is achieved by naming the process that a message is sent to / received from,

e.g. send(P001, message).• BUT, process IDs are problematic – a

process’ ID might be different next time.

• Solution: send to and receive from mail-boxes, e.g. send(mbox1, message).


Summary: ways of sharing data

• Creating a child process

• Shared memory

• Pipes

• Threads

• Message passing system


Reading

• For this lecture, you should (have) read Chapter 4 (Sections 1–4) of Silberschatz et al.

• For the tutorial, you MUST read 4.1 and 4.2.


Next Lecture

SchedulingChapter 5 (Sections 1-3, 7)

Documents

NETW 3005 Threads and Data Sharing. Reading For this lecture, you should have read Chapter 4 (Sections 1-4). NETW3005 (Operating Systems) Lecture 03 -