Kernel - Processes and threads - Management
Processes are created in Phoenix-RTOS using forking technique. When new process is created the current process forks into two processes - parent (process which initializes fork) and child. There are two forking functions used for process creation in Phoenix-RTOS - each of them should be used depending on the platform and MMU presence. The differences between these functions and circumstances of their usage are discussed in this chapter.
Creating new process using
The well-known method of creating new process in general purpose operating systems (e.g. UN*X) is a forking.
The explanation of this method is quite simple. In the certain point of time a thread within a process calls
system call which creates a new process (child process) based on linear address space and operating system resources
used by process calling
fork() (parent process) and launches the thread within a child process. From this point of
time processes are separated, and they operate on their own address spaces. It means that all modifications of process
memory are visible only within them. For example, let's consider process A forking into processes A and B.
After forking, one of the threads of process A modifies variable located at address
addr and stores their value 1
and thread of process B modifies the same variable at address
addr and stores there 2. The modification is specific
for the forked processes, and operating system assures that process A sees the variable located at
as 1 and process B sees it as 2.
This technique can be only implemented when processors are equipped with MMU providing mechanisms for memory
virtualization (e.g. paging) which enables programs to use the same linear address to access different segments of
physical memory. On processors lacked of MMU the
fork() method is unavailable, and it is replaced by
Creating new process using
vfork() is designed to be used in the specific case where the child will
exec() another program, and
the parent can block until this happens. A traditional
fork() requires duplicating all the memory of the parent
process in the child which leads to significant overhead. The goal of the
vfork() function was to reduce this
overhead by preventing unnecessary memory copying when new process is created. Usually, after process creation using
fork() function a new program is executed. In such case, traditional fork before
exec() leads to unnecessary
overhead (memory is copied to the child process and then is freed and replaced by new memory objects as the result of
In UN*X operating system history "The Mach VM system" added Copy On Write (COW), which made the
fork() much cheaper,
and in BSD 4.4,
vfork() was made synonymous to
vfork() function has another important repercussion for non-MMU architectures. Because of semantics, it allows
launching a new process in the same way as using
fork() which enables application portability.
Some consider the semantics of
vfork() to be an architectural blemish and POSIX.1-2008 removed
vfork() from the
standard and replaced it with
posix_spawn(). The POSIX rationale for the
posix_spawn() function notes that that
function, which provides functionality equivalent to
exec(), is designed to be implementable on
systems that lack an MMU.
Process can be terminated abnormally - as the consequence of receiving signal or normally after executing
function. When process exits all of its threads are terminated, all memory objects are unmapped and all resource handles
are freed/closed. The parent process receives
SIGCHLD signal notifying it about the child termination.
signal plays another important role in process termination sequence. It allows to safe remove the remaining child
process resources which are not able to be removed during the process runtime (e.g. last thread kernel stack).
To execute a new program the binary object representing it should be mapped into the process linear address space and
control have to be passed to the program entry point. This is the responsibility of
exec() family functions.
On non-MMU architectures, there is one important step performed after a binary object is mapped and before control is
passed to the program entry point. This step is the program relocation which recalculates some program structures
GOT) used for accessing variables during the runtime. The relocation depends on the current memory location of
While process represents a memory space and operating system resources devoted for particular executed program the
thread represents the program instruction stream executed concurrently to other threads in the process context
(using defined linear address space and associated operating system resources). To manage threads
endthread() functions should be used.
beginthread() function starts a new thread using function address and stack allocated by a calling thread. The kernel
stacks for all of desired thread execution modes are allocated.
endthread() function terminates calling thread and
releases allocated kernel stacks.