Processes: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 8: | Line 8: | ||
[[http://catalogue.pearsoned.co.uk/educator/product/Modern-Operating-Systems-Global-Edition/9781292061429.page Tanenbaum/Bos]] | [[http://catalogue.pearsoned.co.uk/educator/product/Modern-Operating-Systems-Global-Edition/9781292061429.page Tanenbaum/Bos]] | ||
</blockquote> | </blockquote> | ||
A computer program may be defined as the set of <strong>instructions</strong> which | A computer program may be defined as the set of <strong>instructions</strong> which the computer is to follow to perform some computation. Although you probably already know something about machine instructions, in this module we don’t really care about their details; we can think of instructions as lines of source code most of the time. | ||
the computer is to follow to perform some computation. Although you probably already know something about machine instructions, in this module we don’t really care about their details; we can think of instructions as lines of source code most of the time. | |||
However, when a program executes it needs more information: for example it will have variables which store values, many of which will be temporary, but important for a while. In practice there are often several attributes associated with this particular, executing copy of a program, such as who ‘owns’ it, which <strong>files</strong> it is using etc. The executing program, together with this information is typically called a ‘<strong>process</strong>’. | However, when a program executes it needs more information: for example it will have variables which store values, many of which will be temporary, but important for a while. In practice there are often several attributes associated with this particular, executing copy of a program, such as who ‘owns’ it, which <strong>files</strong> it is using etc. The executing program, together with this information is typically called a ‘<strong>process</strong>’. | ||
A typical operating system will allow multiple simultaneous processes. | A typical operating system will allow multiple simultaneous processes. Most will allow the processes to be unaware of each other’s presence, unless the processes specifically want to cooperate. Each process has its own '''[[context]]''' so, for example, you may be able to run two or more copies of the same program on the same machine at the same time without them interfering with each other. | ||
Most will allow the processes to be unaware of each other’s presence, | |||
unless the processes specifically want to cooperate. Each process has | |||
its own '''[[context]]''' so, for example, you may be able to run | |||
two or more copies of the same program on the same machine at the | |||
same time without them interfering with each other. | |||
Most of the process’ [[context]] will be kept in memory. A process will have some <strong>address space</strong> – possibly contiguous addresses, possibly fragmented into several logical [[Memory Segmentation|<strong>segments</strong>]] – which it can use to hold its instructions and variables. This will not encompass all the memory on the machine. The operating system will also hold some private information about the process, typically in a [[Process Control Block (PCB)|process control block]], which may keep track of the various [[resources]] ‘owned’ by this process. | Most of the process’ [[context]] will be kept in memory. A process will have some <strong>address space</strong> – possibly contiguous addresses, possibly fragmented into several logical [[Memory Segmentation|<strong>segments</strong>]] – which it can use to hold its instructions and variables. This will not encompass all the memory on the machine. The operating system will also hold some private information about the process, typically in a [[Process Control Block (PCB)|process control block]], which may keep track of the various [[resources]] ‘owned’ by this process. | ||
Line 24: | Line 18: | ||
Example: if <em>you</em> run a program you don’t specifically attach <em>your</em> name to <em>its</em> data, but the OS may tag it so it can track who is running what. | Example: if <em>you</em> run a program you don’t specifically attach <em>your</em> name to <em>its</em> data, but the OS may tag it so it can track who is running what. | ||
</blockquote> | </blockquote> | ||
The process itself will probably not run continuously. Sometimes it | The process itself will probably not run continuously. Sometimes it may get ‘blocked’ (e.g. waiting for a key-press); if there | ||
may get ‘blocked’ (e.g. waiting for a key-press); if there | are many processes running, sometimes it may get ‘pushed aside’; this [[Process_States|status]] is managed by the | ||
are many processes running, sometimes it may get ‘pushed | |||
aside’; this [[Process_States|status]] is managed by the | |||
operating system’s [[scheduler]]. | operating system’s [[scheduler]]. | ||
<blockquote> | <blockquote> | ||
<strong>Experiment</strong> | <strong>Experiment</strong> | ||
Try some Unix applications such as <code>top</code> or <code>ps</code> (<code>ps -A</code> is a good | Try some Unix applications such as <code>top</code> or <code>ps</code> (<code>ps -A</code> is a good one!) which reveal the currently running processes with some information the OS has kept about them, such as the time they’ve spent being executed. | ||
one!) which reveal the currently running processes with some | |||
information the OS has kept about them, such as the time they’ve | |||
spent being executed. | |||
</blockquote> | </blockquote> | ||
---- | ---- | ||
Line 43: | Line 32: | ||
[[Image:pstree.png|link=|alt=pstree]] | [[Image:pstree.png|link=|alt=pstree]] | ||
At [[boot]] time the first process (number 0) ‘forks’ | At [[boot]] time the first process (number 0) ‘forks’ the <code>init</code> process before becoming the [[idle]] process. <code>init</code> goes on to create “child” processes. The OS maintains information on the parent (in the process’ [[Process Control Block (PCB)|PCB]]). There is a special relationship in that a parent can keep track of its children and children can always enquire who their parent is. | ||
the <code>init</code> process before becoming the [[idle]] process. <code>init</code> goes on to create “child” processes. The OS maintains | |||
information on the parent (in the process’ [[Process Control Block (PCB)|PCB]]). There is a special relationship in that a parent can keep track of its children | |||
and children can always enquire who their parent is. | |||
<blockquote> | <blockquote> | ||
<strong>Stop press:</strong> you may find <code>init</code> has been replaced by <code>systemd</code> | <strong>Stop press:</strong> you may find <code>init</code> has been replaced by <code>systemd</code> in some systems. The <em>principle</em> is unchanged: check the <code>PID</code>. | ||
in some systems. The <em>principle</em> is unchanged: check the <code>PID</code>. | |||
</blockquote> | </blockquote> | ||
A typical example is a [[shell]], which produces a child and (by | A typical example is a [[shell]], which produces a child and (by default) waits for the child to terminate before continuing – | ||
default) waits for the child to terminate before continuing – | informed by a [[Unix Signals|signal]] [https://en.wikipedia.org/wiki/Child_process <code>SIGCHLD</code>]. | ||
informed by a [[Unix Signals|signal]] | |||
[https://en.wikipedia.org/wiki/Child_process <code>SIGCHLD</code>]. | |||
You can display the Unix process tree with the <code>pstree</code> utility; | You can display the Unix process tree with the <code>pstree</code> utility; adding a PID as a parameter shows just that branch. (<code>man pstree</code> may reveal more options.) | ||
adding a PID as a parameter shows just that branch. (<code>man pstree</code> may | |||
reveal more options.) | |||
---- | ---- | ||
==== Orphans ==== | ==== Orphans ==== | ||
If a parent expires before its children, the children are | If a parent expires before its children, the children are ‘adopted’ by <code>init</code>. ([[Daemons]] are created in | ||
‘adopted’ by <code>init</code>. ([[Daemons]] are created in | |||
this way.) | this way.) | ||
<blockquote> | <blockquote> | ||
<strong>Demonstration</strong>: there is a little demonstration of this in the | <strong>Demonstration</strong>: there is a little demonstration of this in the example “orphan.c”. Try compiling and running this from a shell, both with and without a terminal ‘<code>&</code>’ on the command line. Are you confident you can explain the behaviour in each case? | ||
example “orphan.c”. Try compiling and running this from | |||
a shell, both with and without a terminal ‘<code>&</code>’ on the | |||
command line. Are you confident you can explain the behaviour in | |||
each case? | |||
</blockquote> | </blockquote> | ||
---- | ---- | ||
==== Zombies ==== | ==== Zombies ==== | ||
Occasionally you may notice | Occasionally you may notice “[https://en.wikipedia.org/wiki/Zombie_process zombie]” processes. These are child processes which have terminated but this hasn’t been observed by their (real or adoptive) parent. The OS retains the ‘dead’ process’ details until the parent [[Unix Signals|synchronises]] with it. Zombies which persist probably indicate a bug of some sort. | ||
“[https://en.wikipedia.org/wiki/Zombie_process zombie]” | |||
processes. These are child processes which have terminated but this | |||
hasn’t been observed by their (real or adoptive) parent. The OS | |||
retains the ‘dead’ process’ details until the parent | |||
[[Unix Signals|synchronises]] with it. Zombies which persist probably | |||
indicate a bug of some sort. | |||
<blockquote> | <blockquote> | ||
<strong>Demonstration</strong>: there is a little demonstration of this in the | <strong>Demonstration</strong>: there is a little demonstration of this in the example “zombie.c”. Try compiling and running this from a shell. When run the child process terminates first and will remain ‘undead’ for a few seconds. | ||
example “zombie.c”. Try compiling and running this from | Possibly the easiest way to observe this is to be running <code>top</code> (or similar) in another window before starting. | ||
a shell. When run the child process terminates first and will | |||
remain ‘undead’ for a few seconds. | |||
Possibly the easiest way to observe this is to be running <code>top</code> (or | |||
similar) in another window before starting. | |||
</blockquote> | </blockquote> | ||
---- | ---- | ||
*[https://www.bogotobogo.com/Linux/linux_process_and_signals.php Here’s an article] which describes (specifically Linux) processes in quite a lot more detail. It also covers [[Unix Signals|inter-process signals]] in more detail than we do locally. | *[https://www.bogotobogo.com/Linux/linux_process_and_signals.php Here’s an article] which describes (specifically Linux) processes in quite a lot more detail. It also covers [[Unix Signals|inter-process signals]] in more detail than we do locally. | ||
---- | ---- | ||
{{BookChapter|3|106-154}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Concepts}} | {{Category|Concepts}} | ||
{{Category|Processes}} | {{Category|Processes}} |
Revision as of 10:14, 3 August 2019
On path: IPC | 1: Processes • 2: Interprocess Communication • 3: Shared Memory • 4: Files • 5: Unix Signals • 6: Pipes • 7: Sockets • 8: Synchronisation • 9: Synchronisation Barrier • 10: Atomicity • 11: Mutual exclusion • 12: Signal and Wait |
---|
On path: Processes | 1: Processes • 2: Context • 3: Process Control Block (PCB) • 4: Multi Threading • 5: Threads • 6: Interprocess Communication • 7: Process Scheduling • 8: Scheduler • 9: Process States • 10: Process Priority |
---|
Depends on | Resources • Concepts • User |
---|
“A process is fundamentally a container that holds all the information needed to run a program.” [Tanenbaum/Bos]
A computer program may be defined as the set of instructions which the computer is to follow to perform some computation. Although you probably already know something about machine instructions, in this module we don’t really care about their details; we can think of instructions as lines of source code most of the time.
However, when a program executes it needs more information: for example it will have variables which store values, many of which will be temporary, but important for a while. In practice there are often several attributes associated with this particular, executing copy of a program, such as who ‘owns’ it, which files it is using etc. The executing program, together with this information is typically called a ‘process’.
A typical operating system will allow multiple simultaneous processes. Most will allow the processes to be unaware of each other’s presence, unless the processes specifically want to cooperate. Each process has its own context so, for example, you may be able to run two or more copies of the same program on the same machine at the same time without them interfering with each other.
Most of the process’ context will be kept in memory. A process will have some address space – possibly contiguous addresses, possibly fragmented into several logical segments – which it can use to hold its instructions and variables. This will not encompass all the memory on the machine. The operating system will also hold some private information about the process, typically in a process control block, which may keep track of the various resources ‘owned’ by this process.
Example: if you run a program you don’t specifically attach your name to its data, but the OS may tag it so it can track who is running what.
The process itself will probably not run continuously. Sometimes it may get ‘blocked’ (e.g. waiting for a key-press); if there are many processes running, sometimes it may get ‘pushed aside’; this status is managed by the operating system’s scheduler.
Experiment Try some Unix applications such as
top
orps
(ps -A
is a good one!) which reveal the currently running processes with some information the OS has kept about them, such as the time they’ve spent being executed.
Unix process structure
In Unix-like systems there is a hierarchy of processes, in that each process has (or once had) a parent process.
At boot time the first process (number 0) ‘forks’ the init
process before becoming the idle process. init
goes on to create “child” processes. The OS maintains information on the parent (in the process’ PCB). There is a special relationship in that a parent can keep track of its children and children can always enquire who their parent is.
Stop press: you may find
init
has been replaced bysystemd
in some systems. The principle is unchanged: check thePID
.
A typical example is a shell, which produces a child and (by default) waits for the child to terminate before continuing –
informed by a signal SIGCHLD
.
You can display the Unix process tree with the pstree
utility; adding a PID as a parameter shows just that branch. (man pstree
may reveal more options.)
Orphans
If a parent expires before its children, the children are ‘adopted’ by init
. (Daemons are created in
this way.)
Demonstration: there is a little demonstration of this in the example “orphan.c”. Try compiling and running this from a shell, both with and without a terminal ‘
&
’ on the command line. Are you confident you can explain the behaviour in each case?
Zombies
Occasionally you may notice “zombie” processes. These are child processes which have terminated but this hasn’t been observed by their (real or adoptive) parent. The OS retains the ‘dead’ process’ details until the parent synchronises with it. Zombies which persist probably indicate a bug of some sort.
Demonstration: there is a little demonstration of this in the example “zombie.c”. Try compiling and running this from a shell. When run the child process terminates first and will remain ‘undead’ for a few seconds. Possibly the easiest way to observe this is to be running
top
(or similar) in another window before starting.
- Here’s an article which describes (specifically Linux) processes in quite a lot more detail. It also covers inter-process signals in more detail than we do locally.
Also refer to: | Operating System Concepts, 10th Edition: Chapter 3, pages 106-154 |
---|