CSE 5031 Operating Systems

2023/24 Fall Term

Project: 5 – Optional Phase 3 (Bonus)
Topics: Thread Synchronization under Race Conditions
Date: 18.12.2023 –24.12.2023

Objectives:
• To develop a producer consumer application under race conditions.
• To design an application that overlaps its I/O and computing operations.
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

A.1 Definition
This project is the optional Phase 3 of Project 5. It aims to reimplement the producer-consumer scenario you have
developed in the compulsory:
i) under race conditions, that is, producer & consumer threads:
+ communicate using bounded buffers;
+ modify/access shared variables.

ii) overlapping its I/O and computing operations using 3 worker threads input – compute – display to provide
the time line depicted here after.

A.2 Development Support

To support your implementation, the source code of a reference application that coordinate worker threads with
POSIX semaphores and the object code of the solution are stored at the course CATS portal CSE5031 -OS under
the Resources / Project Appendices / Prj5 folder.
• Download “prj5ref3.c” and “solph3” files; and copy them in the “prj5” folder.
• Remove the “x” permission of the “prj5ref3.c” file, if any, using the “chmod a-x *.c” command.
• Set the “rx” permissions of the object code with: “solph*” with “chmod 555 solph*”

IKU / Computer Engineering -page 1/4-

A.3 Analyzing Reference Application “prj5ref3.c”
The reference application consists of 3 worker threads cooperating as producer and consumer pairs that:
✓ share a global buffer between each pair,
✓ coordinate their actions using event semaphores;
✓ control their termination duration using global state variables.

i) The “event” and “mutex” semaphores that are used to coordinate each producer & consumer pair and their
initialization are summarized here after.

ii) Synchronization algorithms implemented by producer & consumer pairs are summarized here after.

Note that:
✓ Transactions ① and ② coordinate for the provision and the release of the shared buffer
✓ Producer & consumer protect their access to critical sections using mutual exclusion semaphores.
✓ Consumer does not block itself to wait for a record to be produced using “sem_wait” primitive.
An event that might never happen! If the producer ends.
Consumer uses the conditional “sem_trywait” primitive to avoid its blocking if the event has not been
posted, skips the computation to check if the producer is terminated or not.

iii) Refer to the above framework to analyze in the reference program how the producer and consumer pairs”
✓ “input – compute” and
✓ “compute - display”
are coordinated and manage race conditions.

iv) Compile & run “prj5ref3.c” to examine the following points.

✓ How the process and its LWPs are defined and associated?
✓ How the application that implements overlapped “input – compute- display” transactions behaves
under different input bursts?
→ Does it discard any of your inputs?
→ Do varying length processing times affect its correct operation?

IKU / Computer Engineering -page 2/4-

 Section B. Implementing & Testing Phase 3
At phase 3, you are asked to restructure the reference application “prj5ref3.c” in three worker threads.
✓ Input and Compute threads remain unchanged.
✓ Display thread takes over the functions implemented by the main thread in the reference application.
✓ Main thread; configures the application context, creates and controls worker threads.

B.1 The Application Context

The application context depicted in Section A.1 shows that:
✓ process’ standard streams are connectedt to the pseudo-terminal “pts/0”;
✓ worker threads display their credentials and state on the flog connection set to the pseudo-terminal “pts/1”;.
✓ display thread writes its outputs to the flog connection.
→ Run the reference application “solph3” and analyze the process/thread context and the IPC framework it creates.

B.2 Implementation Specifications

o Name your source program as “phase3.c”.
o Insert your student-id(s) and name(s) as the first comment line of your program.
o Prefix all the outputs with the label of the thread that has written them.

B.3 Preparing Report Files

i) Capturing Applıcatıon Context
✓ Logon with the “std” account; set the “prj5” folder as the current working directory.
✓ Open two pseudo terminals.
✓ Run on “pts/1” the “dmidecode” command that displays the UUID of the Udt VM.
sudo dmidecode -s system-uuid
✓ Run your application from “pts/0”; it should display worker threads identifiers on “pts/1”.
✓ Run on “pts/1” the commands “ps -lfm -p XXXX” and “pstree –a -p YYYY” hinted by tour application.
✓ If the outputs displayed on “pts/1” contains similar outputs as the screen shut posted here after; take a
screen shut covering all the above transactions and save it as the “p5ph3ctx.png” or “p5ph3ctx.jpg” file.

IKU / Computer Engineering -page 3/4-

 ii) Capturing Application Outputs
Continue step (i) with the following transactions.
✓ Enter on “pts/0 ” :
> your student id;
> your name;
> the end-of-file (ctrl+d).
✓ If the outputs displayed on “pts/1” contains similar lines as the screen shut posted here after; take
ascreen shut and save it as the “p5ph3out.png” or “p5ph3out.jpg” file.

Section C. Project Deliverables

Perform the following procedures to submit your project report.
i) Compress files listed here after using the related document stored under Resources/How to?
✓ “phase3.c” program
✓ “p5ph3ctx.png” or “p5ph3ctx.jpg” file
✓ “p5ph3out.png” or “p5ph3out.jpg” file.
The submitted file should contain only the documents listed above!

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

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 4/4-