Operating Systems Workbench V2.

1
Threads (Threads and Locks) Activities and Experiments
Richard Anthony January 2005
Student name: Phạm Minh Khánh Student ID: ITCSIU21194

This laboratory sheet accompanies the ‘Threads – Threads and Locks’ application within the Operating
Systems Workbench.

1. Prerequisite knowledge
You should have a clear understanding of the following concepts: Operating System, Scheduling,
Process, Thread.
You should have a basic understanding of the following concepts: Lock, Mutual Exclusion, Transaction.
You should be familiar with the ‘Threads – Introductory’ application within the Operating Systems
Workbench.

2. Introduction
This emulation has been designed to introduce you to the fundamentals of locking and mutual exclusion
whilst keeping the complexity low.
Transactions can be executed with and without locks. You can choose at what point within a transaction
to apply a lock, and at what point to release a lock. You can witness the ‘lost-update’ problem in action
and can correct the problem by applying locks appropriately to ensure mutually exclusive access to a
shared variable.
Two threads can be executed separately or simultaneously. Each thread executes update transactions (one
decrements a variable, the other increments it). Without locking, the transactions of the two threads can
interfere with each other.

Figure 1 shows the Threads (Threads and Locks) interface during an emulation in which both threads are
concurrently accessing the shared variable without using locks.

The display is divided into a number of sections. Each section is briefly explained:
 The ‘ADD’ Thread – This thread executes a sequence of one thousand update transactions on a
shared variable. Each transaction reads the current value into thread-local storage, increments the
value locally, and then writes the new value to the shared variable. There is a button to permit
running this thread independently. A transaction counter is updated to allow monitoring of progress.
 The ‘SUBTRACT’ Thread – This thread executes a sequence of one thousand update transactions
on a shared variable. Each transaction reads the current value into thread-local storage, decrements
the value locally, and then writes the new value to the shared variable. There is a button to permit
running this thread independently. A transaction counter is updated to allow monitoring of progress.
 Locking Configuration – Locking can be enabled or disabled (the default). When locking is
enabled the user can elect the point during transactions at which a lock is applied on the shared
variable, and the point at which the lock is released.
 Data Field (shared resource) – This shows the value of the shared variable. The value is initially
1000. A button is provided to reset the value to 1000 before re-running emulations.
 Start both threads button – This starts both threads at the same time. Since they both carry out the
same number of simple updates they tend to complete at approximately the same time too (but this
is not guaranteed or enforced). No synchronisation is applied to the operation of the two threads (or
to their access to the shared variable) unless the user explicitly configures locking.
 Done button – This button exits the application immediately without preserving statistics or
configuration settings. Control is returned to the top-level menu.

1
 Figure 1. The Threads (Threads and Locks) interface.

The following ‘lab activities’ sections describe specific experiments and investigations to help you
maximise the benefit of the software.

Please take care to read the instructions carefully for each step and try to follow instruction sequences
carefully. Try to predict the outcome of experiments in advance if possible. If the outcome is not as
expected try to determine why not. You can repeat experiments as often as required and can work at your
own pace. Try repeating experiments with slight changes in the parameters – sometimes just changing
one parameter slightly can lead to big differences in the results and can shed light on the relative
importance of a particular aspect of the emulation.

For each activity the configuration settings are explained. In each case it is assumed that you have already
started the ‘Introductory Scheduling Algorithms’ simulation application. To do this:
1. Start the Operating Systems Workbench.
2. From the main menu bar, select Threads.
3. From the drop-down menu, select Threads and Locks.

2
Lab Activity 1: Threads: Introductory: Lost-Update 1
Understanding the ‘lost-update’ problem
Threads and Locking>

1. Inspect the initial value of the data field.

Q1. If one thousand increment updates are performed, what value should it end up at?
…It should be end up at 2000……………………………………………………………….………

2. Click the ‘Start ADD Thread’ button to run the ADD thread in isolation.
Q2. Was the result as expected? (if not, check your maths!).

3
………The results are just as expected…………………………………………………….………

3. Note the value of the data field now.

Q3. If one thousand decrement updates are performed, what value should it end up at?
…………It will be 0……………………………………………………………………….………

4. Click the ‘Start SUBTRACT Thread’ button to run the SUBTRACT thread in isolation.
Q4. Was the result as expected? (if not, check your maths!).
…………The results are as expected……………………………………………………….………

4
Q5. If the threads are run sequentially (as above), are there any issues concerning access to the shared
variable that can lead to its corruption?
………There will be a problem called race condition…………………………………….………

5. Click the ‘Reset data field’ button to reset the value of the data variable to 1000.
Q6. Given a starting value of 1000, if one thousand increment updates are performed, and one thousand
decrements are performed, what should the final value be?
………It will be 1000…………………………………………………………………….………

6. Click the ‘Start both threads’ button to run the two threads concurrently.
7. When both threads have finished check their transaction counts to ensure both executed 1000
transactions, hence determine the correct value of the data variable.
………795………………………………………………………………………………….………

5
Q8. Is the actual data variable value correct? If not what could have caused the discrepancy?
……No it isn’t . It could’ve been changed underlying…………………………………….………

Lab Activity 2: Threads: Introductory: Lost-Update 2

Understanding the ‘lost-update’ problem

The Lost-Update 1 activity exposed the lost-update problem.

We saw that a discrepancy occurred between the expected value and the actual final value
of a shared variable.
Some of the updates were lost. This is because one thread was allowed to access the
variable whilst the other had already started a transaction based on the value of the
variable.
Q1. How does this problem relate to transactions in database applications?
……Because when ADD is running the SUBTRACT is also running, however the data
can only give access to 1 of those functions so some update will be missed.
……………………….………

Q2. How many of the ACID properties of transactions have been violated?
……The Isolation properties have been violated………………………………………….
………

Q3. How could this problem affect applications such as:

An on-line flight booking system?
A warehouse stock-management system?
6
……The missing data cannot being recorded correctly might affect that business……….
………

Q4. Think of at least one other real-world application that would be affected by the lost-
update problem?
………booking.com……………………………………………………………………….
………

1. Investigate if the problem has a random aspect, or if the discrepancy is predictable.

Repeat the following steps three times:
A. Ensure the value of the data variable is 1000 (Click the ‘Reset data field’ button if
necessary).
B. Click the ‘Start both threads’ button to run the two threads concurrently.
C. When both threads have finished check their transaction counts to ensure both
executed 1000 transactions, hence determine the correct value of the data variable.
D. Make a note of the extent of the discrepancy.

Q5. Compare the three discrepancies. Is the actual discrepancy predictable, or does it seem
to have a random element?
……Random elements…………………………………………………………………….
………

Q6. If there is a random element, where does it come from (think carefully about the
mechanism at play here – two threads are executing concurrently but without
synchronisation – what could go wrong)?
……Since we cannot predict what will happen if both ADD and SUBTRACT is working
at the same time. In clearer explanation, the data will give access for what function that
performed successfully and the other will cause the lost-
update……………………………………….………

Q7. Is the problem more serious if the discrepancy is predictable? Or if the discrepancy is
not predictable?
……If the discrepancy is not predictable it will be more serious since we cannot control or
adjust to make the lost-update problems disappear when we cannot predict
it…………………….………

Lab Activity 3: Threads: Introductory: Locks 1

The need for locks
The Lost-Update 1 and Lost-Update 2 activities exposed the lost-update problem, and
showed us that the extent of the problem is unpredictable. Therefore, we must find a
mechanism to prevent the problem from occurring.
7
Q1. Could a locking mechanism be the answer? If so, how would it work?
……Yes, in theoretical, the locking mechanism will decide which process wants to get
into the critical section first checks or update the value of the lock
variable……………………….………

Q2. Would it be adequate to apply the lock to only one of the threads, or does it have to
apply to both?
……It should be both……………………………………………………………………….
………

Q3. Is it necessary to use a read-lock, a write-lock, or is it important to prevent both

reading and writing while the lock is applied, to ensure that no lost-updates occur (think
about the properties of transactions)?
……In this transaction only, the write-lock is enough to solve this problem…………….
………

The transactions are a sequence of three stages:

Read the current value into thread-local storage,
Increment (or decrement) the value locally,
Write the new value to the shared variable.

Q4. At what point in this sequence should the lock be applied to the transaction?
…………Before read……………………………………………………………………….
………

Q5. At what point should the lock be released?

………After write……………………………………………………………………….
…………

Investigate the various combinations of locking strategies:

1. Click the ‘Use Locking’ button.
2. Repeat the following steps until all combinations of lock apply and release have been
tried:
A. Ensure the value of the data variable is 1000 (Click the ‘Reset data field’ button if
necessary).
B. Select an option from the APPLY LOCK choices.
C. Select an option from the RELEASE LOCK choices.
D. Click the ‘Start both threads’ button to run the two threads concurrently.
E. When both threads have finished check their transaction counts to ensure both
executed 1000 transactions, hence determine the correct value of the data variable.
F. Make a note of the extent of the discrepancy.

8
Q6. Have you found a combination of applying and releasing locks that always ensures
that there is NO discrepancy? Are you sure – repeat the emulation with these settings a
few times – does it ALWAYS work?
……Yes. It is lock Before READ and release After WRITE and it’s always work……….
………
The first time:

The second time:

9
The use of the lock forces mutually exclusive access to the variable.
Q7. Could you explain clearly to a friend what the above statement means – try it?
…The lock only gives data access to 1 function and the other have to wait until the lock is
released…

Mutual exclusion prevents the lost-update problem.

Q7. Could you explain clearly to a friend what the above statement means – try it?
…Since the mutual exclusion don’t give data access to every function but 1 only, the data cannot
be discrepancy so it cannot have lost-update problems…………………………………….………

10
Threads (Introductory) Activities and
Experiments
Richard Anthony January 2005

This laboratory sheet accompanies the ‘Threads – Introductory’ application within the Operating
Systems Workbench.

1. Prerequisite knowledge
You should have a basic understanding of the following concepts: Operating System, Scheduling,
Process, Thread.

2. Introduction
This simulation has been designed to introduce you to the fundamentals of multi-threading and thread
scheduling whilst keeping the complexity low. Up to three threads can be executed simultaneously. Each
thread is associated with a colour (red, green and blue). Each thread will try to increase its colour
intensity of randomly chosen pixels.
You can investigate the differences between executing a single thread and executing multiple threads.
You can investigate the differences between synchronous scheduling and asynchronous scheduling of
threads. You can investigate the effect of priority on the scheduling.

Figure 1 shows the Threads (Introductory) interface during an emulation of asynchronous scheduling of
three threads each with normal priority.

The display is divided into a number of sections. Each section is briefly explained:
 Schedule Threads Asynchronously (under Operating System control) – The emulation enables
configuration of up to three threads to be scheduled for concurrent execution. Threads can be
created, started and stopped (destroyed) independently.
 Priority – The priority can be set independently for each thread. The options provided are similar to
those typically available to software developers. HIGHEST priority would usually be only used if
the thread had a real-time processing requirement. LOWEST priority would be used for threads that
run in the background and do not need to be responsive to users. Most threads would be scheduled
with the NORMAL priority (the default).
 Schedule Threads Synchronously (under control by the application’s Main thread) – The
emulation enables the three threads to be scheduled for synchronous execution (The threads each
execute for a short time, in sequence. The overall effect is that all threads get regular turns to run –
in a round-robin fashion, but this much coarser-grained than the round-robin scheduling associated
with asynchronous scheduling). Threads are created (and started) and stopped (destroyed)
collectively.
 Interpretation of priority for synchronous threads – The operating system’s internal mechanism
can be used (however, note that with synchronous scheduling only one thread ever executes at a
time as far as the operating system is concerned). Alternatively, priority can be imposed externally
(within the application). In both cases the actual priority values for each thread are taken from the
priority settings discussed earlier.
 Drawing canvas – This area of the display contains a large number of pixels that the threads
compete to colour. The real-time thread-scheduling behaviour can be evidenced in terms of the
relative success of the threads (a thread that is given a greater share of CPU time will manage to
colour more of the pixels).
 Reset drawing canvas button – This paints the entire drawing canvas black, without changing
other settings. It is useful when experiments need to be repeated.
 Cancel button – This button exits the application immediately without preserving statistics or
configuration settings. Control is returned to the top-level menu.
11
 Figure 1. The Threads (Introductory) interface.

The following ‘lab activities’ sections describe specific experiments and investigations to help you
maximise the benefit of the software.

Please take care to read the instructions carefully for each step and try to follow instruction sequences
carefully. Try to predict the outcome of experiments in advance if possible. If the outcome is not as
expected try to determine why not. You can repeat experiments as often as required and can work at your
own pace. Try repeating experiments with slight changes in the parameters – sometimes just changing
one parameter slightly can lead to big differences in the results and can shed light on the relative
importance of a particular aspect of the emulation.

For each activity the configuration settings are explained. In each case it is assumed that you have already
started the ‘Introductory Scheduling Algorithms’ simulation application. To do this:
1. Start the Operating Systems Workbench.
2. From the main menu bar, select Threads.
3. From the drop-down menu, select Introductory.

Lab Activity 4: Threads: Introductory: Single Thread

Introduction to the Introductory Threads application

1. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the RED thread.

2. Press the Start Thread button for the RED thread.

Q1. What happens?

The canvas turned red

12
3. When the drawing canvas has turned completely red, press the Stop Thread button for the RED thread.

Q2. Why were the pixels not coloured evenly (why did some take longer to be coloured red than others)?

Lab Activity 5: Threads: Introductory: Two Threads

Introduction to the Introductory Threads application

A pixel can be any one of a very large number of colours. This is because the density of each
primary colour is represented as a number in the range 0 – 255. Thus, a pixel’s colour is actually
described using three numbers in the format:
pixel colour = (R, G, B)
Where R is the density of the Red colour, G is the density of the Green colour and B is the density
of the Blue colour.
For example (255,0,0) gives a bright red, (0,0,0) is black and (150,150,0) is orange.

The threads each choose a pixel at random and increase the density of their own colour. They also reduce
the density of the other colours.

Q1. What do you think will happen if two threads run at the same time?
It will have race condition

1. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the RED thread.

2. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the GREEN
thread.

3. Press the Start Thread button for the RED thread.

4. After a short time (about three seconds) press the Start Thread button for the GREEN thread.

Q2. What happens?

The yellow start appearing

4. After about twenty seconds, press the Stop Thread button for the RED thread.

Q3. What happens?

The green start to appear most of the screen

Lab Activity 6: Threads: Introductory: Three Threads

Introduction to the Introductory Threads application

Q1. What do you think will happen if three threads run at the same time? What colour will the drawing
canvas appear to be?
The race condition will appear and the canvas will appear the white colour
1. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the RED thread.
13
2. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the GREEN
thread.

3. In the ‘Schedule Threads Asynchronously’ section press the Create Thread button for the BLUE thread.

4. In quick succession, Press the Start Thread button for each of the threads.

Q2. What happens?

Canvas starts appearing the mixture between Red, Green, Blue

5. After about ten seconds, press the Stop Thread button for the RED thread.

Q3. What happens?

Canvas starts appearing the mixture between Green and Blue

6. After another ten seconds, press the Stop Thread button for the GREEN thread.

Q4. What happens?

Canvas starts appearing only Blue

7. You may, up until this point, have been answering the questions in terms of what is happening visually.
Now go back over this activity and consider the questions in terms of the CPU time. Think about how the
CPU time is divided between the threads that are running – how much of a share do they each get?

8. Think about the scheduling of the threads – which scheduling algorithm best describes what you see
happening when all three threads are running (FCFS, SJF, RR or SRJN)? (Make sure you can justify your
answer).

Lab Activity 7: Threads: Introductory: Asynchronous vs

Synchronous Thread Scheduling
Understanding the differences between Asynchronous and Synchronous Thread Scheduling

There are two main ways in which multi-threading can be supported:

 The first approach is to provide support within the Operating System (OS) (so that the OS is
aware of the different threads and allocates processing time to them as appropriate). In the
Introductory Threads application this is referred to as Asynchronous Thread Scheduling
because the interleaving of the threads is fine-grained (as with process scheduling).

 The second approach is to manage the thread scheduling within applications themselves (this is
really a simulation of threading rather than the real thing, but it can have a similar effect). The
OS is not aware that the process contains several threads. In this case the OS simply controls the
amount of processing time allocated to the process overall. Within the application, decisions
must be made as to when to start and stop each ‘thread’. In the Introductory Threads
application this is referred to as Synchronous Thread Scheduling because the interleaving of the
threads is more coarse-grained (the threads appear to run in turns rather than all at once).

14
Experiment with the two different modes of scheduling provided. Use three threads in each case and do
not alter the priority settings.
Q1. Can you clearly see the difference between the two modes of scheduling in terms of the thread
behaviours? To confirm this, think how you would clearly explain what is happening to a friend?
- When the threads run async, all of them run at the same time and create a canvas of difference colors.
Q2. In which mode is it easiest to see that there are separate threads running?

Q3. Which mode would be suitable for an application in which each thread dealt with a different query,
such as a web-server? Why?

Lab Activity 8: Threads: Introductory: Thread Priority

Understanding Thread Priority in both Asynchronous and Synchronous Thread Scheduling

The mechanism of priority is handled differently in each of the two thread scheduling modes:
 In Asynchronous Thread Scheduling the Operating System (OS) is in control. The priority value
is assigned to threads by the OS. This means that the OS will take the priority value into account
automatically when deciding how much processing time to give to each thread.
 In Synchronous Thread Scheduling the OS only knows about the process itself (only one thread
per process is really ever running at a time). Because of this the OS assigned priority values
operate at the process level and have no effect on the relative priority of the threads within the
process. To get around this, it is possible to externally alter the priority of specific threads within
the application itself.

Asynchronous Thread Scheduling.

1. Create and Start three threads. Experiment with various priority configurations.

Q1. What is the visual effect of increasing a thread’s priority?

Q2. What actually causes this visual effect (in terms of the thread scheduling)?

Q3. What is the effect of uniformly increasing the priority of ALL threads to HIGHEST? What is the
effect uniformly decreasing the priority of ALL threads to LOWEST? What is the effect of setting one
thread’s priority to HIGH and setting the other two threads’ priority to LOW? (try also other
configurations).

Q4. Based on your evaluation of the answers to Q3, do you think the priority settings have an:
relative, absolute or relative and absolute
effect on the threads within a single process?

Synchronous Thread Scheduling.

2. Create and Start the threads. Experiment with various priority configurations, USING THE
SCHEDULERS INTERNAL PRIORITY MECHANISM.

Q5. What is the visual effect of increasing a thread’s priority? Why is this?

15
3. Create and Start the threads. Experiment with various priority configurations, USING EXTERNALLY
IMPOSED PRIORITY.

Q6. What is the visual effect of increasing a thread’s priority? Why is this?

Q7. What actually causes this visual effect (in terms of the thread scheduling)?

Q8. What is the effect of uniformly increasing the priority of ALL threads to HIGHEST? What is the
effect uniformly decreasing the priority of ALL threads to LOWEST? What is the effect of setting one
thread’s priority to HIGH and setting the other two threads’ priority to LOW? (try also other
configurations).

Q9. Based on your evaluation of the answers to Q8, do you think the priority settings have an:
relative, absolute or relative and absolute
effect on the threads within a single process?

16