Module 3: Processes

Processes

In Module 1 we defined processes as the context within the operating system where a program executes.
Discussing processes sets the stage for many other upcoming topics, as scheduling, synchronization,
memory management, and even file systems, are all related to processes.

Of course, the concept of processes depends on the type of operating system. A batch operating system
handles one process at a time; in that context a process is usually called a job. If an operating system
allows a job to be suspended, and its state saved, and then allows another job to be executed, it is
demonstrating multiprogramming, and is also related to systems that provide time-sharing.
Multiprocessing operating systems are those that take time-sharing to another level where many
processes can be "ready-to-run" and the scheduler within the kernel can be configured and even
optimized to make the best use of computing resources while still providing a good experience for the
user. Many of us now own "smart-phones" and only recently have these phones been able to run multiple
tasks ("tasks" are one form of "processes") concurrently.

Your assigned reading for this module includes a discussion on how processes are created (Section
2.1.2). We have learned that processes are only created in two ways; either by construction when the
operating system boots up, or by the kernel when the system is running. However, your text does
describe several different circumstances when it is necessary, or at least useful, to request process
creation from the kernel. The shell we discussed in the previous module usually runs as a process that
serves as a command interpreter. One important aspect of this concept is that the commands that are
entered into the shell are executed as new processes (as shown by use of the fork() call).

The UNIX system has traditionally used the fork() call to create new processes. How are processes
created in other operating systems? In Linux (which supports the fork() call), the clone( ) system call was
added to provide more control over how processes are created. When you call fork( ), the entire parent
process is duplicated in the child. Take a look at the manual page on absaroka for clone( ) and see the
degree of control contained in the clone( ) call. clone() allows you to control whether open files are
shared or copied in the child, whether file system information is shared, etc. In Windows operating
systems, the call to create new processes is called CreateProcess( ). This is a much heavier call and it
takes a slew of parameters (see http://msdn.microsoft.com/en-
us/library/ms682425%28v=vs.85%29.aspx) since it combines the functionality of the UNIX fork( ) call with
execve( ). One other operating system, a real-time embedded OS called 'vxWorks', uses a call named
taskSpawn( ) to create new tasks, which is analogous to processes in that operating system. It is also a
fairly complex call.

Once a process is created, it usually enters the system in the Ready state. After you have read section
2.1.5 in your text, note the process transitions that are not allowed. Why can’t you transition from the
Blocked state to the Running state? Why can’t you transition from the Ready state to the Blocked state?

An interesting aspect of processes is how they leave the operation system or in other terms, how do
processes die? Processes either die voluntarily (by returning from the main( ) function or by calling exit( )
) or involuntarily (by encountering a fatal error, either software or hardware, or by being killed by another
process). In UNIX-like operating systems, the involuntary death of a process is implemented by signals in
both cases. In the case of the fatal error, that error would be caught be the kernel and the appropriate
signal (e.g. SIGSEGV for a segmentation violation signal) would be posted to the process which would kill
the process. In the second case, another process would use the kill( ) system call to send a signal (e.g.
SIGKILL) to the process to kill it. We will talk more about signals later.

I like to look at a process as a type of an object (a la OOP); thus a process has a set of attributes (or
properties) as well as a set of methods associated with it. Understanding the attributes of a process is
important, because in a multiprogramming system, the attributes of a process is what makes up the
process state, which must be saved whenever a process is moved from the RUNNING state into either
the BLOCKED state or the READY state. What are some of the attributes or properties of a process?

The video supplied in the module content area goes over some of the process attributes common in
operating systems.

Layout of a Process

Back in Chapter 1, the components of a process are laid out (page 39, Section 1.5.1) Let’s take a look at
that in a little more detail. When laid out in memory, a process is made up of two main pieces — the
instructions that are executed when the process runs, and the memory that is used for storing and
reading data during process execution. The set of instructions as laid out in memory is conventionally
termed the text of the process. In most modern operating systems, the text is usually stored in memory
that is specially marked as non-writeable and executable. If an operating system/computer architecture
allows this, it does make it more difficult to corrupt such a process. Although historically, some programs
were written to deliberately be 'self-modifying' code or text that could be altered as the program executes.

There are several different types of data areas within a process. The stack is a data area within the
process which is a 'LIFO' — last-in, first-out — where automatic data can be pushed on to the stack, used
by the process for a bit, and then popped off. Subroutine or function calls in most high-level languages
push their parameters on the stack where they can then be used by those functions; then the return value
of the function can be pushed onto the stack where the calling procedure can pop it off and store it. Thus,
as a process runs, the more function calls made within the process, the larger the stack grows, until those
calls return and the stack shrinks back.

Another data area in the process is for global data — this is data declared outside of any function within a
program and this is data available for reading or writing by any function within a program at any time.
There are two types of global data — initialized global data and uninitialized global data (although,
curiously, many languages and operating systems do guarantee clearing uninitialized data). Uninitialized
data is termed BSS (from an old assembly term 'block started by symbol'). All global data is established
when the process is initialized — you cannot add more global data as the process is running, nor can you
free the global data from the process. Another data area which can also be globally assessable is called
the heap. The heap is dynamically allocated, and can be freed as the process is running. In C/C++, the
data can be allocated using the malloc( ), alloc( ), or related calls. Thus, the heap can grow and shrink,
just like the stack. Conceptually, the stack and heap are put on different ends of the memory space
available to a process, and then one grows up, while the other grows down and they grow into each
other. How much can the heap or stack grow? It depends on the memory model used by the operating
system, but clearly the operating system cannot allow the heap to grow into the stack, or vice versa. In
operating systems that use virtual memory, which we discuss later, the heap and stack are typically as far
apart as they can be, or at least as far as would make it extremely unlikely for them to meet.

Consider the following source code excerpt:

See if you can figure out where each of the variables in the code snippet fall in the process layout.

Processes vs. Threads

Historically, a process has been the smallest atomic processing element managed by the operating
system, and that processing element typically uses a single CPU. However, when an operating system
has access to multiple CPUs within a computer (which is very common today) you may wish to build the
process such that it can take advantage of multiple concurrent CPUs and operations. The concept of a
thread was introduced as a virtual CPU within a process. Threads are separate execution paths which
can run concurrently in the context of a process. Each thread has its own set of registers, its own stack,
and its own program counter. However, all threads share the global data (and heap) as well as the
process text.

Threads can be implemented in several ways. The first thread implementations were done entirely in user
space by the creation of a thread library. In this case, the process in the kernel is still in a single path of
execution, since there is no operating system support. What are some advantages of this approach?
Modern thread implementations have operating system support; and with multiple cores, you can have
true concurrent operation of multiple threads in a process. (Even without multiple cores, the threads can
be scheduled separately by the kernel).

One of the issues with threads is identifying which attributes are process attributes, and thus are shared
between threads, and which are attributes unique within each thread. (What other advantages to threads
have over processes aside from sharing process attributes?) Figure 2-11 in your text, and the related
discussion, touches on this point.

Some questions on threads:

What do you do with threads within a process when the process forks?

How are signals handled?

How are open files handled?

Think about the topics and questions posed in this module and feel free to address these questions in the
optional discussion. The first project is going to be available this week, and you should spend most of
your time this week (aside from the reading from the text) addressing the project. The quiz for the first
two modules, as well as the first problem set, are due next week. In the next module, we will discuss
interprocess communication methods and synchronization issues.