Designing a Synchronization Mechanism for Your Prototype OS

Deadline

▪ See Blackboard

▪ 15% weight in your final grade

Objectives

The objective is to provide race-free execution for multiple producer/consumer threads through implementation of semaphores.

Tasks

Based on your work in Project II, you need to finish the following tasks.

1. Create 6 producer threads (those with an odd ID number) and 6 consumer threads (with an even ID number) respectively. A producer thread inserts an “X” into a finite circular buffer (with 8 entries) maintained by your prototype_os, and a consumer thread removes an “X” from the buffer. The buffer operates as FIFO. The threads with ID#(0 - 5) perform insertion/deletion operations for 10 times, while other threads (6 - 11)perform the operations for 15 times. A thread should successfully insert/remove its designated number of “X”s.

2. Design a semaphore type to provide mutual exclusion and synchronization for the 8 producer/consumer threads when they are working on the buffer. Each semaphore must have its own blocking/waiting queue, as stated in your textbook.

3. There should be an appropriate delay between a thread’s two consecutive “X” insertion/deletion operations. When a thread gets scheduled, the detailed information about whether its operations on the buffer are successful or it is blocked/unblocked on a semaphore is required to be printed out.

4. After all threads finish, your program is supposed to resume the execution of prototype_os().

Constraints

▪ According to the textbook, a semaphore is required to have a counter variable and a blocking queue.

▪ Required semaphore operations (see Table 1).

Table 1: A Description of Required Semaphore Operations

your_structure_type* mysem_create( int value )	// It returns the starting address a semaphore variable. You can use malloc() to allocate memory space and initialize the internal data structure of the semaphore based on provided parameter.
void mysem_up( your_structure_type* sem )	// It performs the semaphore’s increment operation. Increment the value of the semaphore. If one or more threads are sleeping on the semaphore, the one that has been sleeping the longest is allowed to complete its down operation. As such, after an up on a semaphore with threads sleeping on it, the semaphore value is still 0 but there is one fewer sleeping threads.
void mysem_down( your_structure_type* sem )	// It performs the semaphore’s decrement operation. Check to see if the semaphore value is greater than 0. If so, it decrements the value and just continues. If the value is 0, the thread is put to sleep without completing the down for the moment. As such, the semaphore value never falls below 0.
void mysem_delete( your_structure_type* sem )	// It deletes the memory space of a semaphore.
int mysem_waitCount( your_structure_type sem*)	// Return the number of threads sleeping on the semaphore.
int mysem_value( your_structure_type sem*)	// Return the current value of the semaphore.

▪ The atomicity of executing the critical section can only be guaranteed by your designed synchronization mechanism RATHER THAN by disabling context switching.

Hints

1. Since the NIOS-II ISA does not have the “compare-and-swap” instruction, you have to provide atomicity for the semaphore type, which is similar to what has been done for myinterrupt_handler in Project II. However, the atomicity of executing the critical section should NOT be guaranteed by disabling context switching. Instead, you need to strategically provide atomicity for your semaphore (e.g. when updating the semaphore value) and then use semaphore to provide mutual exclusion for threads

2. Beware of the boundary conditions that a producer (or consumer) thread inserts (or removes) an “X” when the queue is full (or empty).

Submission

Submit a tarball file (in either zip or tar.gz format) packed with the following items by the deadline (see blackboard)

1. A project report that includes:

o the project title & your team members’ names

o an introduction to your project goals, problem description and project management (including project timeline, teamwork, risk anticipation, resources, etc.)

o your key ideas of solving the project problems

o an elaboration of how you accomplish your project tasks (including data structures, algorithms, strategy, etc.) using diagrams, flowcharts, tables or descriptions

o a summary of:

§ what you have accomplished in this project

§ how it can help you understand what you have learned in class

§ your evaluation of the work that you have done (e.g., how creative your proposed idea is, how simple and sweet your design and implementation are, how well your project is organized, etc.)

§ how the course project and its specifications can be improved

o references: list the sources of citations appearing in your report

o format: 11pt Times-New-Roman fonts (the title and section headings can be larger); single-column; 1 inch margins all the way around a page; page numbers; no more than 8 pages in all; DO NOT paste source code with more than 10 lines; diagrams/charts/graphs with brief explanations are more preferable than thousands of words; submitted as a PDF file.

2. A folder containing your project source code with meaningful comments, as well as a README file that details the organization of your own source code (e.g., what each file is used for and how they function together) , as well as how to compile and run the program. Please DONOT include any files or folders automatically generated by the NIOS-II IDE!

Grading Criteria (Rubric)

1. Project report: 30%

2. Correctness of the program: 60%

3. Detailed source code comments and README: 10%

Typically, all members in a team will get the same grade for a project, unless the team leader or other members report to the grader that someone contributes little to the project and he/she should get only a certain percentage (e.g., 90%) of the team’s grade.