CS4411
Practicum in Operating Systems

# Overview

We have provided you with some skeletal code that creates an environment on top of (Windows,OSX,Linux) that closely resembles the environment on top of raw hardware shortly after booting. We use our host OS to provide us with a virtual processor and memory. It also bootstraps our kernel; that is, it loads it into memory and starts executing it at its entry point. Your task is to build high-level abstractions on top of this environment in the same manner the host OS builds its abstractions on top of the hardware.

There are a few distinct components to this project.

• First, you will have to write some generic FIFO (first-in, first-out) enqueue and dequeue operations. We will be relying on this queue implementation throughout the rest of the semester, so it's important that the implementation be efficient. Specifically, enqueue and dequeue operations should both work in O(1) time.
• Second, you need to define and implement thread control blocks, and the functions that operate on them. We suggest you start with minithread_create and minithread_yield, and go on to implement the scheduler. Once you have those two working, you can come back to implement the rest of the functionality.
• Third, you need to implement a scheduler. For this assignment, all you need is a first-come, first-served scheduler. You can assume that your threads will voluntarily give up the CPU, which means that your test programs should make occasional calls to minithread_yield().
• Fourth, you need to implement semaphores in order to be able to synchronize multiple threads.
• Finally, you need to implement a simple "retail store" application that uses your minithread, queue, and semaphore implementations. The application models customers and employees at an electronics retail store as threads. Your application should make the best possible use of the components you developed in this project to simulate the following:
• It is release day for the new PortPhone 5, the latest device running the revolutionary PortOS from Sirer Systems. Customers are flocking to their local retail store to purchase the new phones. Unfortunately, the new shipment of phones has just arrived and employees are struggling to keep up with demand.
• There are N employees . Each employee constantly unpacks phones. Each phone has a unique serial number, and the phones are unpacked in increasing serial order.
• There are M customers, who are served on a first come, first served basis. When a customer arrives at the store, they immediately receive a new phone if one is available. Otherwise, they wait in line until more phones become available. Ensure, for sanity
• When a customer receives a phone, (s)he immediately activates it by printing the unique serial number to stdout.

# How to get started

## Windows

To unpack and set up minithreads, do the following:

For Visual Studio 2008/2010:

1. Unzip the PortOS1.zip file in the directory for your project.

2. In VS2008/2010, select File -> New -> Project from Existing Code.

3. Create a C++ project and choose the PortOSWin directory (inside the directory created when you unpacked PortOS1.zip).

4. Name the project minithreads and under File types to add to the project replace the list of extensions with "*" to add all files in the directory.

5. Click the Next button, choose Use external build system, click Next again.

6. Make the following entries:
• Under Build command line enter: nmake.
• Under Rebuild command line enter: nmake /a.
• Under Clean command line enter: nmake clean.
7. Click Next and Finish.

Different combinations of Windows (32/64 bit), Microsoft SDK and Visual Studio will have different path settings. We provide some examples below. Make sure to edit the Makefile for your architecture accordingly (and have only one of these versions uncommented).

• If you are running 32-bit Windows / VS 2008, the top of your Makefile should have the following lines uncommented:

SDKLIBPATH = "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib"
VCLIBPATH = "C:\Program Files\Microsoft Visual Studio 9.0\VC\lib"
WINVER = "WIN32"
MACHINE = "I386"
PRIMITIVES = machineprimitives_x86_asm

• If you are running 32-bit Windows / VS 2010, the top of your Makefile should have the following lines:

SDKLIBPATH = "C:\Program Files\Microsoft SDKs\Windows\v7.0A\Lib"
VCLIBPATH = "C:\Program Files\Microsoft Visual Studio 10.0\VC\lib"
WINVER = "WIN32"
MACHINE = "I386"
PRIMITIVES = machineprimitives_x86_asm

• If you are running 64-bit Windows / VS 2008, the top of your Makefile should have the following lines uncommented:

SDKLIBPATH = "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\x64"
VCLIBPATH = "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64"
WINVER = "WIN64"
MACHINE = "X64"
PRIMITIVES = machineprimitives_x86_64_asm

• If you are running 64-bit Windows / VS 2010, the top of your Makefile should have the following lines uncommented:

SDKLIBPATH = "C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64"
VCLIBPATH = "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64"
WINVER = "WIN64"
MACHINE = "X64"
PRIMITIVES = machineprimitives_x86_64_asm


In order to build in 64-bit mode, you may need to add a 64-bit configuration to you IDE. To do so, open the Configuration Menu(Build > Configuration Manager), and select x64 as the platform. If x64 is not an option, select "new" from the platform drop-down menu and select x64 from the "New platform" box. Finally, click OK.

After modifying the Makefile, open a Visual Studio 2008/2010 Command Prompt through the Windows start menu:

1. Start

2. All programs

3. Microsoft Visual Studio 2008/2010

4. Visual Studio Tools

5. Visual Studio 2008/2010 Command Prompt

Note

If you are on Windows x64 (64-bit), you should use the Visual Studio 2008/2010 x64 Command Prompt.

Enter these commands into the command prompt to build and run your application:

> cd "C:\path\to\PortOS1\PortOSWin"
> nmake


If you decide not to use the Visual Studio integrated development environment, you can use any other editor you like and compile the code from the command line (using the instructions above).

## Linux, OSX

Check the HACKING file in the respective folder for complete explanations on how to get started on these platforms. You will need to install the autoconf and libtool packages.

Please install XCode if you use OSX to do the project. You can get it from App store for free or get it from here.

# How to Test Your Code

It's crucial that systems code be correct and robust. You must test your code with reasonable and unreasonable test cases, and ensure that it behaves correctly. Note that you should maintain some separation between the minithread package and minithread applications. Most notably, your minithread applications should not contain any dependencies on the scheduling algorithm or on the lack of preemption.

To facilitate testing, we provided you with some test programs. It's a good idea to start with these, and develop your own tests as you need them.

Here's a list of test cases, each with a short description:

test1.c
A test of single thread creation.
test2.c
A test of multiple thread creation.
test3.c
A test of ping-pong between two threads.
buffer.c
A bounded buffer implementation. A producer and consumer keep producing and consuming values across a buffer of finite length.
sieve.c
A Sieve of Eratosthenes for concurrently searching for primes. It has a single thread on one end, injecting the numbers 1, 2, 3, 4, 5, 6, 7, 8, ... into a pipe. For each prime p, there is a thread in the middle of the pipe that consumes a number from the pipe if that number is divisible by p. Otherwise, it passes the value on to the next thread in the pipe. At the very end, there is a thread that prints the values that emerge from the pipe. Note that this assembly will only print out prime numbers, because the threads in the pipe will consume all non-primes.

Since we will soon make the threads package preemptive, all code you write should be properly synchronized. That is, everything should work no matter where in the application thread you place a minithread_yield. Consequently, it's a good idea to test your code with minithread_yields inserted at random locations throughout the application code (note that we don't expect the system code in minithread.c or synch.c to be yield-safe for this project - just the applications).

Do not forget to check for memory leaks. Your threads package should not run out of memory when large numbers of threads are created and destroyed.

# Submissions

Use CMS to submit your project. Only submit source files in a single zip file with the code is placed in an ARCHITECTURE/P1 directory. Replace ARCHITECTURE with PortOSWin or PortOSnix or PortOSX, depending on the operating system you use in the project. So, if you used Windows for Project 1, we expect a zip file containing the hierarchy PortOSWin/P1/*, where * represents all your source files. In this folder you should also include a README file with your name, your partner's name, and anything you think we should know. This includes documenting any broken functionality (although you will have trouble later on if you do not complete this project now, so you should not be submitting a broken project).

Note: These suggestions for an extra challenge will be examined but not graded. They will have no impact on the class grades. They are here to provide some direction to those who finish their assignments early and are looking for a way to impress friends and family (or perhaps better understand the material).