Simulation of Multithreading on Single Threaded
Operating Systems
Chandrajit G. Joshi
ABSTRACT
Single threaded operating system is that which
itself runs as single threaded and does not support
multithreading at the kernel level. A very good
example of this is HP NonStop™ Kernel that is
used in most of the business critical applications
including all major stock exchanges and in
finance and telecom sectors across the world.
HP NonStop™ Kernel operating system has
"Loosely Coupled, Shared Nothing" architecture,
in the sense that each CPU in the system has its
own copy of operating system and RAM, and any
two processes in the system communicate with
each other through messages. This paper aims to
discuss ways multithreaded programs can be
written to run on such operating systems.
Categories and Subject Descriptors
D.1.3 [Concurrent Programming]:
General Terms
Programming, Operating System, Input/Output
(I/O)
Keywords
Multithreading, Ready list, Thread-control-block,
Task-control-block, Blocked and Unblocked I/O.
1. INTRODUCTION
The word "multithreading" can be translated as
multiple threads of control or multiple flows of
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without written permission
provided that copies are not made or distributed for profit or commercial
advantage and that copies bear this notice and the full citation on the
first page. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee.
TATA Consultancy Services Ltd, Air India Building, Mumbai
control within a process. Threads are a
mechanism to allow a process to perform more
than one activity at a time. Application
programmers choose to write multithreaded
programs when they want to achieve
• Improved performance and concurrency
• Simultaneous access to common resources
• Reduced usage of system resources
• Efficient usage of multiprocessors
These threads are also called as user level threads
since they are a part of user application
programs. There are some operating systems such
as Unix, which identify and support these user
level threads and have mechanisms at the kernel
level to manage them. But, programmers have
problems developing multithreaded applications
for the operating systems, which do not support
user level threads. This paper suggests two
approaches for implementing user level threads
in the application programs on such operating
systems.
2. APPROACH 1
In this approach, a thread will be nothing but a
function-procedure executing independently of
the mainline code of process. Each thread will
execute on a stack different from that of main
stack of the process. All the threads will be
initialized, scheduled, started and managed by a
"Thread Module" in the mainline code using data
structures such as thread-control-block (ThCB),
and doubly linked lists called as thread-ready-list
and wait list. “Thread Module” is a library of
function-calls that provides functions for
management of user level threads. Real challenge
in this approach is to develop the Thread Module.

ThCBs, thread-ready-list and wait-list will be
allocated and initialized at the process startup
time. Thread-ready-list will contain those ThCBs
that are to be launched by the Thread Module.
Wait list will contain those ThCBs that are
waiting for an event completion. The event could
be an I/O, timeout or any other application
specific event. ThCBs will be allocated for all the
executing threads and they will hold the context
information necessary for swapping the threads
in and out. This information will include
• Name of the function-procedure running as
thread
• Thread stack address
• Current stack pointer
• Program counter
• Information about the last operation (I/O or
timeout) initiated by the thread
• Priority of the thread, if priority based
scheduling is selected
2.1 THREAD SCHEDULING
Thread scheduling will be done in “First In First
Out (FIFO)” manner. Alternatively, programmers
can assign a priority number for each thread.
Higher number will indicate high priority thread
and so on. In priority based scheduling, ThCBs
will occupy the position in ready list depending
on their priorities, with highest priority thread at
the head of ready list. If two threads have same
priority, FIFO method can be adopted for their
scheduling. Fig. 1 shows the ready list. Each
block represents a ThCB. ThCBs are arranged in
the descending order of their priorities i.e. P1 >
P2 > P3…. > Pn
HEAD
NEXT NEXT NEXT
P1 P2 P3 . . . . . . . .
PREV PREV PREV
Fig. 1
A thread will represent a path of code execution
within the process. It will perform some activity
in response to a triggering event. Hence a thread
will be scheduled either in response to an
external event like an incoming request message
or an internal event like housekeeping. It will be
the responsibility of thread scheduler to swap out
a thread when the thread initiates a blocked I/O
or if it calls a system function that suspends the
process for specified interval of time (e.g. delay
function in Unix). A thread will be swapped in
when an event for which the thread is waiting for,
occurs. This event could be I/O or delay
completion. The thread ends when the function-
procedure returns.
2.2 THREAD SYNCHRONIZATION
Two synchronization models can be used to
achieve thread synchronization for concurrently
executing threads to control program flow and
access to shared resources.
• Mutex locks allow only one thread at a time
to execute a specific section of code, or to
access specific data.
• Counting semaphores typically coordinate
access to resources. The count is the limit on
how many threads can have access to a
semaphore. When the count is reached, the
semaphore blocks.
2.3 ILLUSTRATIVE PSEUDO CODE
Following pseudo code is just an illustration and
hence variations in the implementation depending
on the programming style and nature of the
program are possible. Each pseudo code is
followed by its explanation. “C” style pseudo
code has been used just for the ease of
understanding. One may choose to write the
TAIL actual code in any suitable programming
NEXT language.
Pn
PREV
2.3.1 Pseudo Code of main()
main ()
{
 DECLARE and INITIALIZE local variables.
CALL init_Process().
CALL init_Thread_Module().
CALL open_Files().
WHILE (TRUE)
{
CALL listner().
SWITCH (Request Type)
{ thread_Dispatch() launches and executes all the
READ : CALL thread_Schedule(READ).
WRITE : CALL thread_Schedule(WRITE).
UPDATE : CALL thread_Schedule(UPDATE).
QUIT : RETURN.
. thread that is currently waiting for the event
. completion, then it takes the corresponding
DEFAULT: CALL process_Unknown_Request().
} /* End of SWITCH */
WHILE (There are ThCBs in the ready list)
{ In this pseudo code, thread_Dispatch() is the
CALL thread_Dispatch().
CALL thread_IO_Completion().
} /* End of WHILE there are ThCBs */
} /* End of WHILE TRUE */
} /* End of main() */
2.3.2 Explanation of main()
Function init_Process() initializes all the global
data-structures except ready list, wait list and
ThCBs. init_Thread_Module() initializes all the
ThCBs, the ready list and the wait list. It also
schedules all the threads that perform internal
activities like housekeeping. It is important to
schedule them before entering in the main
processing loop because these threads are not
triggered by external events. The function
open_Files() opens all the files including
database and process files. It opens them in such
a mode that it will enable performing blocked
IOs on them. Process then enters the request-
listening loop, which is the main processing loop.
Function listener() listens to all kinds of external
requests. It returns as soon as it gets a request.
The SWITCH case that follows listener()
executes appropriate case depending on the type
of request. The function thread_Schedule()
allocates a ThCB and execution stack for the
appropriate function depending on the type of
request received, and places the ThCB in the
ready list. This function will then be launched as
thread. process_Unknown_Request() handles all
the undefined requests. Function main() returns if
the request type is QUIT. Process then enters the
thread execution loop and does not exit from it
till there are ThCBs in the ready list.
threads in the ready list and returns only when
there are no threads in it.
thread_IO_Completion() checks for any event
completion (e.g. IO or timeout). If there is any
thread from the wait list and puts it in the ready
list according to its priority.
most important function because when it finds a
ThCB in the ready list, it launches the thread. In
other words, the execution jumps to the entry
point of the function. Following pseudo code
illustrates a function that will execute as a thread.
2.3.3 Pseudo Code of read_From_DB()
This function will be scheduled as a thread when
the request type is READ. The function
thread_Schedule() schedules it in the main().
read_From_DB()
{
/* This function reads into a buffer from a
given database file in blocked mode */
DECLARE and INITIALIZE local variables.
CALL threadIO_Read().
RETURN to the caller.
} /* End of read_From_DB() */
2.3.4 Explanation of read_From_DB()
threadIO_Read() reads from a given file in
blocked mode. But, before that it saves the
information about thread stack in ThCB. This is
important because the thread will be swapped out
when it initiates the I/O for READ operation.
This function also puts the ThCB in the wait list.
threadIO_Read() can only be called by a thread.
Finally, the function returns to the caller. The
caller here is a “Thread Module” function i.e.
thread_Start(). Details about it are given in Fig.
2.
In this approach, process need not manage delays
and timeouts, since OS itself will manage them.
Delays and timeouts will especially be useful in
the housekeeping threads. Such threads will
normally run throughout the life cycle of the
process. In other words, these are long running
threads. The following pseudo code shows this.
2.3.5 Pseudo Code of garbage_Cleanup()
garbage_Cleanup()
{
/* This is a housekeeping function. This
function runs as a thread after every 30
minutes and in each run, it cleans up all
the scratch files created by the process */
DECLARE and INITIALIZE local variables.
WHILE (TRUE)
{
CALL delete_Stray_Files().
CALL thread_Delay() for 30 minutes.
} /* End of WHILE */
} /* End of garbage_Cleanup() */
2.3.6 Explanation of garbage_Cleanup()
This function executes an infinite loop, since it is
a long running thread. delete_Stray_Files() does
the job of file deletion. thread_Delay() saves the
context information of the thread in its ThCB, put
it in wait list and calls system function delay().
When 30 minutes are over, execution starts from
the code-statement following the call to delay().
Fig. 2 shows how program execution will jump
from main stack of the process to the thread stack
Function thread_Start() will be a “Thread
Module” function that sets up the thread
environment for read_From_DB() function. It
also de-allocates all the thread related resources
allocated to read_From_DB() when it returns.
Direction of stack growth
Direction of stack growth
thread_Dispatch() read_From_DB()
Jumps to
main() thread_Start()
Main stack Thread stack
Fig. 2
3. APPROACH 2
The second approach is based on the assumption
that the operating system should provide setjmp()
and longjmp() or similar system-calls. The first
one is to save the current process context in a
buffer and the second one is to unconditionally
jump to the saved process context from anywhere
within the process. For example, HP NonStop™
Kernel provides this service by providing two
system-calls called SETJMP_ and LONGJMP_
In this approach, a task that is performing a set of
sequential and interrelated activities can be
treated as a thread. As in the first approach, a
thread will be scheduled as a result of a
triggering event.
Unlike the first approach, here all the threads will
execute on the main stack of the process. In this
approach, the process will have two modes of
execution - kernel mode and task-execution
mode. Each task will be identified by a data
structure called task-control-block (TCB) and the
task scheduling will be managed using a task-
ready-list. A TCB will contain all the context
information about the task. This will include
• Name of the task
• Next dispatch-state of the task. This tells the
task what to do next
• Event for which task is waiting for
• Latest event occurred for which the task was
waiting
• Timeout value when the task wants to
timeout or cancel the operation if the event
does not occur in specified interval of time
• Result of last I/O completion
• Pointers to the buffers if the task is using any
for doing any operation
• Priority of the task, if priority based
scheduling is selected
In task-execution mode, process will call
appropriate function according to the dispatch-
state of the task. The function will perform the
sequential and interrelated activities, which the
task is meant for. The process will return back to
kernel mode whenever it initiates an event like
I/O or timeout completion. In this approach, the
process should initiate all the I/Os and timeouts
in unblocked mode.
Unlike in the first approach, management of
delay or timeouts will have to be managed by the
process itself. This can be done by a timeout list.
It will be similar to ready list, but the TCBs will
be placed in the ascending order of their timeout
values i.e. T1 < T2 < T3… < Tn as represented in
Fig. 3
HEAD TAIL

• The value of step. If a task performs 5 NEXT NEXT NEXT NEXT

sequential and inter-related activities and if TO = T1

PREV
TO = T2

PREV
TO = T3

PREV
. . . . . . . . TO = Tn

PREV

currently it is performing 3rd activity, then

step will have value 3. This is explained in Fig 3

more details in the pseudo codes

3.1 ILLUSTRATIVE PSEUDO CODE
Task-ready-list will be a doubly linked list
similar to the thread-ready-list, where TCBs will
3.1.1 Pseudo Code of main()
be placed. These will be the TCBs representing main ()
those tasks that are to be launched by the process {
while in Kernel mode. The scheduling of tasks DECLARE and INITIALIZE local variables.
can either be FIFO or programmers may adopt
the priority based scheduling in this approach as CALL init_Process().
well. Any one task will be active at any point in
time. A global structure pointer, say CurTCB, CALL open_Files().
will identify currently active / executing task.
CALL thread_SetEnv(jmpBuf).

In Kernel mode, process will be responsible for IF ready list is NOT empty
establishing threading environment for the GOTO launch_The_Task.
process. In this mode, it will also be responsible
for detecting and processing I/O and timeout CALL listener().
completions, setting the next dispatch-states for
various tasks according to the result of last I/O or SWITCH (Request Type)
timeout completion and launching the tasks {
according to their respective dispatch states. READ: CALL process_Read().
WRITE: CALL process_Write().
UPDATE: CALL process_Update().
 QUIT: RETURN.
E.g. for READ request, process_Read() is called.
.
process_Read() allocates a TCB for this request
.
and sets all the structure members of TCB like
DEFAULT: CALL process_Unknown_Request().
name of task, its priority, to appropriate values.
} /* End of SWITCH */
A check for TCBs in the ready list is again made,
IF ready list is NOT empty
and the tasks are launched if there are any.
GOTO launch_The_Task.

If there are no tasks in the ready list, a check for

IF checkTO() THEN timeout completion is made. This is done by
process_TO_Completion().
checkTO(). It returns TRUE if there is a timeout
completion for a task. It determines this by
IF checkIO() THEN
scanning through the timeout list.
Process_IO_Completion().
Process_TO_Completion() sets the appropriate
next dispatch-state for the task that has timed out
Launch_The_Task:
and puts the TCB in the ready list according to its
SET CurTCB to the first TCB in ready list
priority.

SET CurTCB->step TO 1. If there is no timeout completion, process checks

SWITCH (Next Dispatch State of CurTCB)
{
READ : read_From_DB().
WRITE : write_In_DB().
UPDATE : update_DB().
.
.
.
} /* End of SWITCH */
} /* End of main */
3.1.2 Explanation of main()
As in the first approach, init_Process() initializes
all the global data-structures. But here,
initialization includes TCBs and the ready list
also. open_Files() opens all the database and
process files. It opens them in such a mode that
they will enable performing unblocked IOs on
them. Process enters the Kernel mode in the
thread_SetEnv() function. This function calls
setjmp() or an appropriate similar function
provided by OS, to establish the threading
environment. If there are TCBs in the ready list,
the task at the head is launched (this is done by
GOTO to Launch_The_Task). listener() listens to
all kinds of external requests. Depending on the
type of request, appropriate function is called.
for I/O completion by calling checkIO(). It
returns TRUE if there is an I/O completion.
process_IO_Completion() determines for which
task, the I/O has completed, saves the result of
I/O in the TCB, sets the appropriate next
dispatch-state for the task and puts it in the ready
list according to its priority.
Under the label Launch_The_Task, CurTCB is
set to the first TCB in the ready list. “step”
parameter of CurTCB is then set to 1 to indicate
that the task will perform first in the whole set of
activities. Finally, depending on the dispatch-
state of the TCB, appropriate function is called.
In this approach, how the process determines I/O
completion is completely OS dependent.
Normally, operating systems provide system-calls
to determine this. They also provide calls to
cancel an I/O if it does not complete within
specified time limit. In this way, process can
perform timeouts on I/O operations.
3.1.3 Pseudo Code of read_From_DB()
read_From_DB()
{
/* This function performs READ operation on a
 given database file in unblocked mode */
Write_In_DB task

DECLARE and INITIALIZE local variables.

Read_From_DB
IF (CurTCB->step IS EQUAL TO 1) Other tasks PROCESS
task
DATABASE
{
CALL thread_ReadDB(FILE1).
Update_DB
task

SET CurTCB->step TO 2.
Fig. 4

CALL thread_Swapout(). There are possibilities of race conditions in this

} /* End of step 1 */
approach. E.g., the memory pool for buffers used
in the I/O operations is a common resource and
IF (CurTCB->step IS EQUAL TO 2)
two or more tasks can compete for acquiring
{
buffers from it. To avoid race conditions and to
CALL thread_ReadDB(FILE2).
synchronize various tasks, the data structure
CALL thread_Swapout().
governing the pool will have a queue. If a task
} /* End of step 2 */
tries to acquire a buffer from this pool and the
} /* End of read_From_DB */
buffer of required size is not available, TCB will
put in this queue. When the buffer becomes
available, the TCB will be put back in the ready
3.1.4 Explanation of Pseudo Code list from where it will be launched by the Kernel
As evident from the pseudo code, the function is mode.
used to read from two database files. Hence the
whole activity has been divided in two steps. So
these steps become small inter-related activities, 4. CONCLUSION
in the sense that process cannot go to second Programmers can use any of these approaches in
before it finishes first. thread_ReadDB() sets up developing multithreaded applications to run on
the environment for initiating the I/O and then single threaded OS to get the benefits of
initiates READ in unblocked manner. It then sets multithreading at the application level, if not at
the step of CurTCB to 2 so that when the the kernel level. Products, which have adopted
function is called the next time, it will directly go these approaches, are already available on HP
to step 2 in the function. thread_Swapout() calls NonStop™ platform.
longjmp() with an appropriate return value.
Hence the control goes back to setjmp() in the
main() function. After each step, the function
gives control back to Kernel and waits for the I/O
initiated in the earlier step to complete.

The process is depicted in the Fig. 4. Each task is

executing independently of each other. At any
point in time, any one task is active and all other
tasks are either waiting for an event or are
suspended.
5. ACKNOWLEDGMENTS
I am thankful to my colleague Mr. Jyoti Ranjan
Nayak for reviewing this document and
providing some very good suggestions. I would
also like to thank my Project Leader Mr. Arun
Jambotkar, Account Manager Mr. Royen
Fernandes and Group Leader Mr. Gopal Menon
for their continuous support.

6. REFERENCES
[1] Hewlett-Packard, “User Level Native Thread
Primitives”, www.hp.com
[2] “Advanced Linux Programming”,
www.advancedlinuxprogramming.com