CSE 5031 Operating Systems

2023/24 Fall Term

Project: 5
Topics: Thread Synchronization Basics
Date: 12.12.2023 – 24.12.2023
Objectives:
• To develop multithreaded applications using POSIX Pthreads API.
• To implement thread synchronization using POSIX semaphores API.
References:
• Linux man pages “man pthreads” , “man sem_overview” and https://man7.org/linux/man-pages/
• Lawrence Livermore National Laboratory Computing Center POSIX Threads Programming | LLNL HPC Tutorials
• Linux System Programming 2d ed., Robert Love, O’Reilly 2013 (CATS/CSE5031 – Home / Resources / References)
• The GNU C Library Reference Manual (http://www.gnu.org/software/libc/manual/pdf/libc.pdf )

Section A. Project Definition and Phases

A.1 Process / Thread Synchronization Paradigm

Applications controlling concurrent activities are implemented with cooperating processes and/or threads that:
→ share data either directly through their virtual address space, or indirectly through data repositories or the
messages they exchange; and
→ use data generated by each other.
The activities of cooperating processes and/or threads must be synchronized in order:
→ to preserve the consistency of shared data;
- they must not modify shared data at the same time, and must prevent others access until they finalize their
update (atomic actions)-,
→ to coordinate their flow of execution
-they must start executing only when data becomes available, or the event to be monitored has occurred.-

Race condition refers to the situation where the outcome of a computation

depends either on the moment or the execution order of concurrent activities.

A.2 Project Purpose and Scope

The project aims at reimplementing the producer – consumer scenario, studied in Project 3, using threads, to
create the context depicted here after. The main thread of the process’ creates & controls:
✓ a producer thread that reads varying length records from stdin and writes them to the “data.txt” file;
✓ a consumer thread that reads a record from “data.txt” file, if any, and displays it on pts/1.

”
Note that, the drawing does not show the standard streams associated with the pseudo-terminal “pts/0”.

IKU / Computer Engineering -page 1/6-

A.3 Project Phases
The producer – consumer scenario will be implemented with or without creating race conditions between them.
i) Phase 1 will implement a no-race solution, using an unbounded buffer (a shared file) and coordinating
“producer” & “consumer” threads with independent state variables and busy wait loops.
ii) Phase 2 will implement the race version of phase 1, in which threads will still share an unbounded buffer
but coordinate their activities using shared variables controlled with POSIX Semaphores.
iii) optional Phase 3 (Bonus) will implement a race solution, using a bounded buffer (a circular queue) and
coordinating “producer” & “consumer” threads using shared variables controlled with POSIX Semaphores.

A.4 Development Support

To give you a jumpstart in multithreaded programming with POSIX pthreads and POSIX semaphores, 2 reference
programs and the object codes of the solutions for phase 1 and 2 are provided at the course CATS portal.
• Logon to Udt VM using the “std” account and create the “prj5” folder under your Home directory.
• Download “prj5ref1.c” , “prj5ref2.c”, “solph1”, “solph2” files from Resources / Project Appendices / Prj5
folder; and copy them in the “prj5” folder.
• Remove the “x” permission of “prj5refx.c” files, if any, using the “chmod a-x *.c” command.
• Set the “rx” permissions of the object codes with: “solph*” with “chmod 555 solph*”

A.5 Analyzing the Reference Application “prj5ref1.c”

The first reference application implements a partial non-race solution for Phase 1. It creates a producer thread and
implements consumer thread functionality in the main thread.

i) Application Context
Compile& run “prj5ref1.c”, and display:
✓ the multi-threaded hierarchy;
✓ the IPC framework;
✓ the FDT table entries of the process.
Familiarize with the use of commands that
display the LWPids and threads as Linux tasks.

ii) Implementing Phase 1 without race condition

The producer-consumer scenario defined in Phase 1 has been implemented without race condition
considering the following design criteria.
✓ Producer and consumer threads share an unbounded buffer, a data file that does not require their
coordination since:
o The buffer space is unlimited (unlike a shared memory buffer), and the producer may write its
records irrespective of consumer’s reading frequency. In fact, data files also have limited capacity,
but it is huge considering the IPC load generated by the application.
o Producer and consumer threads do not modify any common record stored on the shared file,.
o Producer and consumer threads use two different connections, corresponding to two different FDT
entries. Thus, each thread has its own file position pointer.
o Read/write operations from/to the shared data file are atomic. OS drivers initiate a read or a write
operation once the previous operation is completed.
o The producer forces OS to write is records (fflush) without delay.

✓ Producer and consumer threads maintain their own record counter; consumer reads the record count
variable maintained by the producer; thus, the integrity of the shared variable is not compromised.

IKU / Computer Engineering -page 2/6-

 ✓ The consumer thread periodically reads the status variable maintained by the producer; to decide for
its own termination; and does not require producer’s intervention.

while ( “producer” is alive OR data file has new records ) {

if ( log file has new records) {
read a record ;
display the record }
}
sleep (1); // to emulate processing overhead
}
printf (“consumer> terminating \n”); …….

Note that this solution waits for 1 extra second to terminate in case the producer ends but
consumer has not yet displayed the last record. But, this mishap is harmless, and consumer
termination delay is acceptable.

Section B. Implementing the Non-Race Solution (phase 1)

At Phase 1, you will create the application context depicted in Section A.2 , by restructuring “prj5ref1.c” - the
reference application- as two threads that run under the control of the main thread;.
✓ Producer thread remains unchanged; it reads varying length inputs from stdin & writes to the “data.txt” file.
✓ Consumer thread takes over the functions implemented by the main thread in the reference application.
It reads “data.txt” file and displays retrıved records at the pseudo-terminal pts/1.

B.1 The Application Context

Run the reference application “solph1” and analyze the multi-thread context and the IPC framework it creates.
You are strongly advised to draw the complete IPC framework created by the application, including:
✓ standard streams of the threads that are associated with the pseudo-terminal “pts/0”; and
✓ the 3d pseudo-terminal pts/2 connection.

B.2 Implementation Guidelines

Name your application as “phase1.c”.

i) The Parent process (main thread)

✓ Requests the opening of pseudo terminals pts/1 and pts/2 before continuing.
✓ Displays on pts/2 its PID, LWPid etc.
✓ Sets the status of producer thread to “ended” and creates the producer thread.
✓ Creates the consumer thread.
✓ Waits for the termination of both treads.
✓ Displays its own termination message on on pts/1 and returns.

ii) The Producer Thread

Remains unchanged and performs exactly the actions defined in the reference application.
iii) The Consumer Thread
✓ Displays its TID, LWPid, and PID.
✓ Waits for the producer thread state to become “ready”.
✓ Performs the actions defined in the reference application.
✓ As the producer ends and it has displayed all the records stored in the data file; prints its termination
message.
✓ Returns a NULL pointer.
IKU / Computer Engineering -page 3/6-
B.3 Reporting Part 1
i) Compile “phase1.c”.and name the object program “phase1”.
ii) Run “phase1” from pseudo-terminal pts/0; open the 2d and the 3d pseudo-terminals as requested.
iii) Enter on “/dev/pts/0” the following inputs:
✓ your student id;
✓ your name
iv) Display on “/dev/pts/2” the thread context your application creates (like the one posted here after)

v) Take the screen shut of pts/2” covering the entire output generated by your application and save it as the
“ph1 pst2.jpg” or “ph1 pst2.png” file.
vi) On pts/0 enter the EOF character to end your application; the output displayed on pts/1 should be like the
one posted here after.

vii) Take the screen shut of “/dev/pts/1” covering the entire output generated by your application and save it as
the “ph1 pst1.jpg” or “ph1 pst1.png” file.

Section C. Implementing the Race Solution (phase 2)

At Phase 2 will implement the race version of the application defined in phase 1, in which threads will still share an
unbounded buffer but coordinate their activities using shared variables controlled with POSIX Semaphores.

C.1 Analyzing the Reference Application “prj5ref2.c”

i) Application Context
The application context remains the same. Compile, run “prj5ref2.c”, and display
✓ the multi-threaded hierarchy;
✓ the IPC framework;
✓ the FDT table entries of the process.
ii) Implementing Phase 2 with race conditions
The second reference program “prj5ref2.c” shows how the producer-consumer scenario is implemented
with race conditions, as it considers the design criteria outlined here after.
✓ Producer and consumer threads coordinate their activities, such as waiting for the creation of the
data file using an event semaphore initialized to 0 (not happened).
✓ Producer & consumer threads keep the integrity of the shared record using a mutual exclusion
semaphore initialized to 1 (first requestor gains the access, the 3d waits until the first exits the
critical section).

IKU / Computer Engineering -page 4/6-

C.2 Implementation Guidelines
i) Name your application as “phase2.c”.
ii) Update “phase2.c” following the procedures outlined in B.2

C.3 Reporting Part 2

i) Compile “phase2.c”, and name the object program “phase2”.
ii) Run “phase2” from pseudo-terminal pts/0; open the 2d and the 3d pseudo-terminals as requested.
iii) Enter on pts/0 the following inputs:
✓ your student id;
✓ your name
iv) Display on “/dev/pts/2”
✓ the UUID of the Udt VM with “sudo dmidecode -s system-uuid”
✓ the process thread hierarchy your application creates (should be like the one posted here after).

v) Take the screen shut of pts/2 covering the entire output generated by your application and save it as the
“ph2 pst2.jpg” or “ph2 pst2.png” file.
vi) On pts/0 enter the EOF character to end your application; the output displayed on pts/1 should be like the
one posted here after.

vii) Take the screen shut of pts/1 covering the entire output generated by your application and save it as the
“ph2 pst1.jpg” or “ph2 pst1.png” file.

Section D. Project Deliverables

i) Compress files listed here after using the related document stored under Resources/How to?
✓ “phase1.c” “ph1 pst1.jpg” or “ph1 pst1.png” “ph1 pst2.jpg” or “ph1 pst2.png” files
✓ “phase2.c” “ph2 pst1.jpg” or “ph2 ps1.png” “ph2 pst2.jpg” or “ph2 pst2.png” file

The submitted file should contain only the documents listed above!

ii) Store compressed report in the Prj5:CSE5031-group# folder located under Assignments heading at the
CATS course portal CSE5031 OS.

IKU / Computer Engineering -page 5/6-

 Collaboration Rules: What is Allowed What is NOT
Collaboration is a great way to learn. Students are encouraged to discuss project concepts and
confer on implementation procedures with their peers. The key is to use collaboration as a way to
enhance learning, not as a way of sharing answers without understanding.
To avoid plagiarism all prose and code that you write for projects must be your own original work.
Any other source you use must clearly identify and accurately cited.
The submitted work should be exclusively yours; copying or getting help from a third party is
prohibited. Your submissions should be kept confidential, sharing them is cheating. No distinction
will be made between those who cheat and who facilitate cheating by revealing their submissions.

IKU / Computer Engineering -page 6/6-