CSE 30 -- Lecture 16 -- Nov 24

Assignment 6

Extend the coroutine threads package to include locking, thread priorities, and more dynamic thread creation. You must implement the following functions:

void lock_init(struct lock *);
void lock_acquire(struct lock *);
void lock_release(struct lock *);
void thr_set_pri(struct thr_state	*thr,
		 int			priority);

in MIPS assembly.

The lock_init initializes a lock structure, which is allocated by the application programmer. You, as the systems programmer, will modify the threads package to provide the new interface; you may assume that the application programmer will correctly use the thread interface.

The lock structure variable must keep track of whether the lock has been acquired or not. That is the only requirement. A more featureful lock design might include a record of which thread ``owns'' the lock, i.e., that acquired the lock originally, so as to generate an error message if a thread different from the owner tries to release the lock. Your code should only keep track of whether the lock is available for acquiring or not.

In your implementation, you should create a lock_header.mips to include a

LOCK_SIZE=4 # or whatever size is required, and offsets to fields, if any

I'll provide a modify header.mips with additional PRIOFF and PRISTATE offsets, which should be the only changes needed to the thread_state structure. I'll also provide a version of student.mips, which will include code to initialize the default thread priority to 1.

The interpretation of the thread priority is as follows: while we do not perform preemptive scheduling, we still try to provide priorities to threads by modifying the round-robin scheduling slightly. A thread with a priority of 1 will run every time through the thread table; this is a high priority thread. A thread with a priority of n will run only once every n time that we scan through the thread table.

Life Optimization

The game of life: a rectangular region is divided into a grid. Each grid point may be marked as "alive" or "dead". We look at a 3x3 neighborhood around each grid point. Each pixel has, ignoring itself, 8 neighbors in this grid. We compute the new grid state as follows. A cell is alive if it had exactly 3 living neighbors in the old grid state. A cell is marked as the same state that it was in before (alive or dead) if in the old grid it had exactly 2 living neighbors. A cell is marked dead otherwise.

To understand how we represent the grid, we must first look at how systems code talk to hardware devices. For the life grid, we will assume that we have a black-and-white mode for our video card, and that the video RAM (VRAM) is mapped into memory for direct access. First, some generic information about hardware.

Hardware devices are accessed by having special ``registers'' be accessed by the processor. These registers are accessed using either special I/O instructions, or are accessed using normal load/store instructions. under construction!

bsy+www@cs.ucsd.edu, last updated Mon Nov 30 21:53:20 PST 1998.

email bsy & tutors