SE 3313A – Operating Systems
Lab 2: Threads and
Semaphores




Due: Check OWL for your lab section deadline

Lab 3: Threads and Semaphores
2
1. SE 3313A – Lab 2: Threads and Semaphores
Objective
The objectives for this lab are as follows:
1. Write an application that spawns and kills multiple threads
2. Work with semaphores
3. Work with UNIX shared memory objects
4. Practice working with existing code
Introduction

This document contains a lot of information. This section describes the tasks for Lab 2 while
section 2 “Resources for Lab 2” provides additional information for completing this lab. I
STRONGLY recommend that you read it all the way through.

In this lab, you will create two applications, called Reader and Writer, starting from the code at
this repository:

https://github.com/kgrolinger/se3313-2020-lab2

Writer is a (minimally) user-interactive application. It repeatedly asks if the user would like to
create a new thread. As long as the user keeps answering “yes”, it then asks (for each new thread)
what the thread wait time should be. The user enters some number of seconds (let’s call it N).

The Writer then spawns a new thread with sleep time of N seconds. Each thread has the SAME
job, which is to write some information to a shared memory object once every N seconds. The
information to be written is thread Id, report Id (ie: how many times has this thread reported)
and metric of how much time has passed since the last report. Each write operation overwrites
what was previously in the shared memory object.

This process continues, with the Writer spawning new threads every time the user says “yes”. In
principle your system should accept an unlimited number of threads, but you shouldn’t need to test
it for more than three or four. Once the user says “no”, the Writer should cancel the threads, wait
for them to die, and exit.

Reader has only one job, which is to monitor the contents of the shared memory location and
report to the user. It does not need to accept user input, but rather runs for some fixed time, or until
you kill it.

Here is a picture of two terminals, one running Writer and the other running Reader.
Lab 3: Threads and Semaphores
3


You need to perform the two tasks: one without semaphores and one with semaphores.

RECOMMENDATION: Use provided classes, such as Thread, Semaphore, and Shared to
implement the two versions. Sections 2 “Resources for Lab 2” of this document provides
descriptions of the provided classes. Writer class (Writer.cpp) you obtain from GIT includes
a possible starting point for the use of those classes.

I. Task 1: No Semaphore Version

Write a Writer/Reader pair that does not use semaphores. In this case, you will probably want to
use sleep() or usleep() to let Reader periodically poll the shared memory.

It is important to note that this version of the software SHOULD NOT WORK correctly. The entire
point of semaphores is that things like this should not work correctly. Once you have the code
running, let it run for a while and see if you can find evidence of failure. Answer the following
question:

Question 1: Can you find evidence of a thread report getting obliterated? That is to say, some
thread should have reported and you can’t find its report? For example, thread #3’s report #4 is
just gone? What is causing this? (In this case, I expect you will certainly see such events.)

Submit your code as per instructions in the deliverables section. With answers to question 1,
provide evidence of your program function.

II. Task 2: Semaphore Version

Re-create the system properly with semaphores. Reader must read the buffer before another Writer
overwrites it. Reader shouldn’t need to poll anymore.

Lab 3: Threads and Semaphores
4
In this case, please answer the following questions:

Question 2: Explain your semaphore design. How are the semaphores being used? What is their
function? How do they affect the various threads and processes?

Question 3: Do you still see any corrupt or missing reports? Could you see any corrupt or missing
reports? Explain.

Submit your code as per instructions in the deliverables section. With answers to questions,
provide some evidence of your program function.

Deliverables
1. ZIP file with code for task 1
• Name your submission: se3313a-username-lab2_1.zip
2. ZIP file with code for task 2
• Name your submission: se3313a-username-lab2_2.zip
3. PDF file with answers to questions 1 to 4 and discussion

If the student did not demo the solution to TA during the schedule lab time due to illness or other special
circumstances (with documentation as per the course outline), the student must contact his/her assigned
TA as soon as possible. For no demo, 50% of the available mark will be deducted.


Lab 3: Threads and Semaphores
5
2. Resources for Lab 2
I. Compilation

Compiling with shared memory objects, semaphores and threads is pretty complicated and requires
both compilation and link options. Accordingly, a Makefile has been provided for this assignment.
Makefiles are basically a way to simplify maintaining programs and working with command line
options. In the IDE, such as Visual Studio, all the checkboxes you specify to select build options
eventually get turned into a Makefile. Automatically generated ones tend to be very difficult to
read. Hand-crafted ones, on the other hand, are usually quite simple. A part of the Makefile
provided with your Assignment 2 looks like this:



This text creates two make “targets”: one called “Reader” and one called “Writer”. What it says,
translated into English, is as follows:

There is a thing I would like you to make, called “Reader”. It depends on three files, called
Reader.o, thread.o, and Blockable.o. If any of those three files is newer than the file called
Reader, then run g++ with the command line options as specified.

If you cloned the provided repository, you’ll have all the files you need to compile provided code
using Makefile. Then, at the command line, you type make Reader, and the compilation for Reader
happens. To compile all, you can just type make. If you want to add your own header files, you
can add them to the dependency line, to trigger automatic compilation when you change the
headers.

II. Creating and Destroying Threads

A class called Thread provided with this assignment wraps up threads functionality into an object-
oriented C++ version. Using the provided Thread class is the recommended approach, but you can
also directly use std::thread

III. 1 Provided Thread class

This class is provided in files thread.h and thread.cpp.
Thread::ThreadMain is what is called a “pure virtual function” in C++. What that means is that
you can’t create an object of type Thread. What you do instead, is create your own class, that
inherits from Thread. As long as your class implements YourClass::ThreadMain, the thread will
be spawned in your code, but it will inherit the behaviour of the base class. Of course, if you want
Lab 3: Threads and Semaphores
6
more than one different kind of threads running in the same application, you can make more than
one class, each of which inherits from Thread.

Thread Termination
“Killing” a thread is now frowned upon by operating system purists. The preferred approach is to
write your thread as a loop that can be terminated externally. In Thread class provided with this
lab, the Blockable family makes this flexible (see provided Writer.cpp for use).

Notice that Thread contains a Sync::Event called terminationEvent. The LAST thing
ThreadFunction does is trigger this event. As a result, you can wait on this event in your
destructor to make a blocking destructor. Thus, you can allow delete to block and make sure that
the thread has actually terminated before you try to clean up any resources it needs. You may find
this functionality useful in creating threads that terminate without causing system crashes, core
dumps, and unhandled exceptions.


III.2 Working directly with std::thread

If you really want to work directly with threads, C++-11 includes a thread object in the std
namespace. A brief review of its operation is provided here:

The constructor for std::thread looks like this:


As you can see, it is a generic class. The syntax is complicated, and includes the notion of an r-
value reference (specified by &&) and a variable parameter list. Fortunately, we don’t really have
to worry about the details. Basically, what you do is define a Function and provide its Arguments.
The Argument list can have variable length, but must match the arguments expected by the
Function, with one exception. Options for Function are:
1. A plain old function, defined at file scope (static or not). In this case, the Argument list is
the same as the arguments to the function
2. A static member function of a class. In this case, the Argument list is the same as the
arguments to the function
3. A non-static class member function. This is the exception. In this case the first Argument
MUST BE a pointer to an instance of the class. It will become the this pointer when the
thread is executed. The thread then has access to all of that instance’s member data.

Most of the time, all you want to do with a std::thread object is join() it, which blocks the parent
until the thread’s Function returns.

“Killing” a thread is now frowned upon by operating system purists. The preferred approach is to
write your thread as a loop that can be terminated externally. With std::thread, basically it means
having a Boolean variable and checking it each time through the loop.

Lab 3: Threads and Semaphores
7
III. Shared Memory Objects

In order to use semaphores, we need to have some kind of resource for them to protect. The classic
example is a shared memory location, or shared memory object. You can think of it as a dropbox
that different threads and/or processes can read and/or write at different times to pass messages.
This is basically creating a producer/consumer situation, except that arriving threads overwrite
what is there and the “buffer” has only one element.

Fortunately for us, POSIX supports a very powerful mechanism for creating named shared
memory objects. Unfortunately for us, this mechanism is kind of complicated. For the purposes of
this lab, a template class called template class Shared is provided. This template is
located in a file provided, called SharedObject.h.

A template allows you to write “generic” code, then instantiate specific versions of it by specifying
a type for T. In other words:

Shared sharedInt("john "); //Creates a shared integer object called “john”
Shared sharedPoint("origin "); // Creates a shared object called “origin” of some class Point

You have access to the source code for template Shared, but here’s how it works.



These are the constructor and destructor of Shared. The constructor takes two parameters. The
first one, name, is a string you provide to identify the object. The second parameter is a Boolean
variable that identifies whether the creator of the object should be its owner. The notion of
“ownership” requires some explanation. A shared memory object in UNIX is a chunk of special
memory, allocated on a special heap that is different than the one new uses. What makes it special
is that multiple processes and threads can each have their own pointers to the same chunk of
memory, as long as they know the name of the chunk, and the chunk was created to allow multiple
use. Unfortunately, these objects are not reference counted, and there is no garbage collection.
There is a function that causes the object to cease to exist (shm_unlnk), but once that is called,
nobody new can use the memory, although people who already have it can still use it.
Shared is used as follows:
• Each thread or process that wants to use shared point “origin” has to create its own version
of:
Shared sharedPoint(“origin”);
• One (and only one) of them should identify itself as the owner. In this case, it’s probably
the parent thread of Writer, who should instead call
Shared sharedPoint(“origin”, true);
• In this way, as long as all your threads and processes use the same name for the shared
object, you can access the same piece of memory across threads, and even across process
boundaries.
Lab 3: Threads and Semaphores
8

Most of Shared is variations on this theme. Basically, Shared acts like what we call a
“smart” pointer. It contains within it a block of memory of size sizeof(T). As long as the only way
to access that memory is through pointers of type T*, all users of the same named object can
pretend that it is a T. So, the member function get() gives you a T* to work with.

However, since C++ has all kinds of operator overloading capabilities, in provided code, several
things are overloaded so that an object of type Shared has pretty much exactly the same syntax
as a T*. Suppose, for example, that you have:


Then you create:

Assuming somebody has created a shared Point called “origin”, you can now do things like:
theOrigin->x = 0; theOrigin->y=0; and all other users will see it. You can even call theOrigin-
>Move(1,1); and all other users will see that, too.

NOTE ON USAGE: Because shared objects live in, and are created in, a special shared heap, they
can’t be resized. Don’t try to create something like Shared or Shared
or anything like that.

IV. Semaphores

Just as was the case with shared memory, POSIX contains a powerful built-in mechanism to
implement named, counted semaphores. A class Semaphore is provided to simplify matters
somewhat.



Semaphores are named in exactly the same way as shared memory objects, and have the same flaw
(they are not reference counted either). So, the same approach is used to deal with one-owner-
many-users. Once the destructor is called, the name will cease to exist. Nobody new will be able
to access the semaphore, but current users will not be forced to give it up. Only the owner (creator)
can specify the initial state. Since this is a counted semaphore, any integer can be the initial state.

Lab 3: Threads and Semaphores
9


V. Time

Some of the data that needs to be stored in the shared space is time. UNIX has the following
function, which you may find useful:

time_t time(time_t *t)

time() returns the number of seconds since 12:00:00 am on New Year’s Day, 1970. While this may
strike you as a somewhat arbitrary number, it does mean that the difference between two successive
calls to time() is a measurement of how many seconds elapsed between them.




欢迎咨询51作业君