| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this assignment, we give you a minimally functional thread system. Your job is to extend the functionality of this system to gain a better understanding of synchronization problems.
You will be working primarily in the threads
directory for
this assignment, with some work in the devices
directory on the
side. Compilation should be done in the threads
directory.
Before you read the description of this project, you should read all of the following sections: 1. Introduction, C. Coding Standards, E. Debugging Tools, and F. Development Tools. You should at least skim the material from A.1 Loading through A.5 Memory Allocation, especially A.3 Synchronization.
The first step is to read and understand the code for the initial thread system. Pintos already implements thread creation and thread completion, a simple scheduler to switch between threads, and synchronization primitives (semaphores, locks, condition variables, and optimization barriers).
Some of this code might seem slightly mysterious. If
you haven't already compiled and run the base system, as described in
the introduction (see section 1. Introduction), you should do so now. You
can read through parts of the source code to see what's going
on. If you like, you can add calls to printf() almost
anywhere, then recompile and run to see what happens and in what
order. You can also run the kernel in a debugger and set breakpoints
at interesting spots, single-step through code and examine data, and
so on.
When a thread is created, you are creating a new context to be
scheduled. You provide a function to be run in this context as an
argument to thread_create(). The first time the thread is
scheduled and runs, it starts from the beginning of that function
and executes in that context. When the function returns, the thread
terminates. Each thread, therefore, acts like a mini-program running
inside Pintos, with the function passed to thread_create()
acting like main().
At any given time, exactly one thread runs and the rest, if any,
become inactive. The scheduler decides which thread to
run next. (If no thread is ready to run
at any given time, then the special "idle" thread, implemented in
idle(), runs.)
Synchronization primitives can force context switches when one
thread needs to wait for another thread to do something.
The mechanics of a context switch are
in threads/switch.S
, which is 80x86
assembly code. (You don't have to understand it.) It saves the
state of the currently running thread and restores the state of the
thread we're switching to.
Using the GDB debugger, slowly trace through a context
switch to see what happens (see section E.5 GDB). You can set a
breakpoint on schedule() to start out, and then
single-step from there.(1) Be sure
to keep track of each thread's address
and state, and what procedures are on the call stack for each thread.
You will notice that when one thread calls switch_threads(),
another thread starts running, and the first thing the new thread does
is to return from switch_threads(). You will understand the thread
system once you understand why and how the switch_threads() that
gets called is different from the switch_threads() that returns.
See section A.2.3 Thread Switching, for more information.
Warning: In Pintos, each thread is assigned a small,
fixed-size execution stack just under 4 kB in size. The kernel
tries to detect stack overflow, but it cannot do so perfectly. You
may cause bizarre problems, such as mysterious kernel panics, if you
declare large data structures as non-static local variables,
e.g. int buf[1000];
. Alternatives to stack allocation include
the page allocator and the block allocator (see section A.5 Memory Allocation).
Here is a brief overview of the files in the threads
directory. You will not need to modify most of this code, but the
hope is that presenting this overview will give you a start on what
code to look at.
loader.S
loader.h
start() in start.S. See section A.1.1 The Loader, for details. You should not need to look at this code or modify it.
start.S
kernel.lds.S
start.Sto be near the beginning of the kernel image. See section A.1.1 The Loader, for details. Again, you should not need to look at this code or modify it, but it's here in case you're curious.
init.c
init.h
main(), the kernel's "main
program." You should look over main() at least to see what
gets initialized. You might want to add your own initialization code
here. See section A.1.3 High-Level Kernel Initialization, for details.
thread.c
thread.h
thread.hdefines
struct thread, which you are likely to modify
in all four projects. See A.2.1 struct thread and A.2 Threads for
more information.
switch.S
switch.h
palloc.c
palloc.h
malloc.c
malloc.h
malloc() and free() for
the kernel. See section A.5.2 Block Allocator, for more information.
interrupt.c
interrupt.h
intr-stubs.S
intr-stubs.h
synch.c
synch.h
io.h
devicesdirectory that you won't have to touch.
vaddr.h
pte.h
flags.h
devicescode
The basic threaded kernel also includes these files in the
devices
directory:
timer.c
timer.h
vga.c
vga.h
printf()
calls into the VGA display driver for you, so there's little reason to
call this code yourself.
serial.c
serial.h
printf() calls this code for you,
so you don't need to do so yourself.
It handles serial input by passing it to the input layer (see below).
block.c
block.h
ide.c
ide.h
partition.c
partition.h
kbd.c
kbd.h
input.c
input.h
intq.c
intq.h
rtc.c
rtc.h
thread/init.cto choose an initial seed for the random number generator.
speaker.c
speaker.h
pit.c
pit.h
devices/timer.cand
devices/speaker.cbecause each device uses one of the PIT's output channel.
libfiles
Finally, lib
and lib/kernel
contain useful library
routines. (lib/user
will be used by user programs, starting in
project 2, but it is not part of the kernel.) Here's a few more
details:
ctype.h
inttypes.h
limits.h
stdarg.h
stdbool.h
stddef.h
stdint.h
stdio.c
stdio.h
stdlib.c
stdlib.h
string.c
string.h
debug.c
debug.h
random.c
random.h
-rskernel command-line option on each run, or specify the
-roption to
pintos.
round.h
syscall-nr.h
kernel/list.c
kernel/list.h
kernel/bitmap.c
kernel/bitmap.h
kernel/hash.c
kernel/hash.h
kernel/console.c
kernel/console.h
kernel/stdio.h
printf() and a few other functions.
Proper synchronization is an important part of the solutions to these
problems. Any synchronization problem can be easily solved by turning
interrupts off: while interrupts are off, there is no concurrency, so
there's no possibility for race conditions. Therefore, it's tempting to
solve all synchronization problems this way, but don't.
Instead, use semaphores, locks, and condition variables to solve the
bulk of your synchronization problems. Read the tour section on
synchronization (see section A.3 Synchronization) or the comments in
threads/synch.c
if you're unsure what synchronization primitives
may be used in what situations.
In the Pintos projects, the only class of problem best solved by disabling interrupts is coordinating data shared between a kernel thread and an interrupt handler. Because interrupt handlers can't sleep, they can't acquire locks. This means that data shared between kernel threads and an interrupt handler must be protected within a kernel thread by turning off interrupts.
This project only requires accessing a little bit of thread state from interrupt handlers: for the alarm clock, the timer interrupt needs to wake up sleeping threads. When you access these variables from kernel threads, you will need to disable interrupts to prevent the timer interrupt from interfering.
When you do turn off interrupts, take care to do so for the least amount of code possible, or you can end up losing important things such as timer ticks or input events. Turning off interrupts also increases the interrupt handling latency, which can make a machine feel sluggish if taken too far.
The synchronization primitives themselves in synch.c
are
implemented by disabling interrupts. You may need to increase the
amount of code that runs with interrupts disabled here, but you should
still try to keep it to a minimum.
Disabling interrupts can be useful for debugging, if you want to make sure that a section of code is not interrupted. You should remove debugging code before turning in your project. (Don't just comment it out, because that can make the code difficult to read.)
There should be no busy waiting in your submission. A tight loop that
calls thread_yield() is one form of busy waiting.
In the past, many groups divided the assignment into pieces, then each group member worked on his or her piece until just before the deadline, at which time the group reconvened to combine their code and submit. This is a bad idea. We do not recommend this approach. Groups that do this often find that two changes conflict with each other, requiring lots of last-minute debugging. Some groups who have done this have turned in code that did not even compile or boot, much less pass any tests.
Instead, we recommend integrating your team's changes early and often, using a source code control system (we strongly recommend git) and a group collaboration site such as Github, GitLab, or Bitbucket. This is less likely to produce surprises, because everyone can see everyone else's code as it is written, instead of just when it is finished. These systems also make it possible to review changes and, when a change introduces a bug, drop back to working versions of code, as well as provide a backup copy of your code.
You should expect to run into bugs that you simply don't understand while working on this and subsequent projects. When you do, reread the appendix on debugging tools, which is filled with useful debugging tips that should help you to get back up to speed (see section E. Debugging Tools). Be sure to read the section on backtraces (see section E.4 Backtraces), which will help you to get the most out of every kernel panic or assertion failure.
Before you turn in your project, you must copy the
project 1 design document template into your source tree under the name
pintos/src/threads/DESIGNDOC
and fill it in. We recommend that
you read the design document template before you start working on the
project. See section D. Project Documentation, for a sample design document
that goes along with a fictitious project.
Reimplement timer_sleep(), defined in devices/timer.c
.
Although a working implementation is provided, it "busy waits," that
is, it spins in a loop checking the current time and calling
thread_yield() until enough time has gone by. Reimplement it to
avoid busy waiting.
timer_sleep() is useful for threads that operate in real-time,
e.g. for blinking the cursor once per second.
The argument to timer_sleep() is expressed in timer ticks, not in
milliseconds or any another unit. There are TIMER_FREQ timer
ticks per second, where TIMER_FREQ is a macro defined in
devices/timer.h. The default value is 100. We don't recommend
changing this value, because any change is likely to cause many of
the tests to fail.
Separate functions timer_msleep(), timer_usleep(), and
timer_nsleep() do exist for sleeping a specific number of
milliseconds, microseconds, or nanoseconds, respectively, but these will
call timer_sleep() automatically when necessary. You do not need
to modify them.
The alarm clock implementation is not needed for later projects, although it could be useful for project 4.
Implement producer/consumer communication through a bounded buffer, using locks and condition variables only. The producer places characters from the string "Hello world" into the buffer one character at a time; it must wait if the buffer is full. (Once the producers reach the end of the string they should stop.) The consumer pulls characters out of the buffer one at a time and prints them to the screen; it must wait if the buffer is empty. Test your solution with a multi-character buffer and with multiple producers and consumers. Of course, with multiple producers or consumers, the output display will be gobbledygook. However, note that a correct solution will not produce arbitrary output!
Your solution should accept two arguments (which are passed as parameters to the functions invoked by the tests we provide) which correspond to the number of producer threads and the number of consumer threads. Your solution will be graded through code inspection to verify the correctness of the synchronization algorithms (in addition to basic functionality checks of the running code).
You have been hired by the City of Saarbruecken to synchronize traffic over a narrow bridge. Traffic may only cross the bridge in one direction at a time, and if there are ever more than 3 vehicles on the bridge at one time, it will collapse under their weight. In this system, each car is represented by one thread, which executes the procedure OneVehicle when it arrives at the bridge:
OneVehicle(int direc, int prio) {
ArriveBridge(direc,prio);
CrossBridge(direc,prio);
ExitBridge(direc,prio);
}
|
In the code above, direc is either 0 or 1; it gives the direction in which the vehicle will cross the bridge. The parameter prio indicates if this is an emergency vehicle (when it is set to the value 1), in which case it should have priority over other vehicles. When such a vehicle wants to cross the bridge it should be allowed access as soon as possible.
The main part of this assignment is to write the procedures ArriveBridge and ExitBridge, using semaphores only. (You must also implement the CrossBridge procedure, but this should just print out a debug message upon entrance, sleep the thread for a random amount of time, and print another debug message upon exit.) ArriveBridge must not return (i.e., it blocks the thread) until it is safe for the car to cross the bridge in the given direction. ExitBridge is called to indicate that the caller has finished crossing the bridge; ExitBridge should take steps to let additional cars cross the bridge (i.e., unblock them). This is a lightly-travelled Saarbruecken bridge, so you do not need to guarantee fairness or freedom from starvation, other than what has been indicated for emergency vehicles.
You should hand in a program that takes four parameters which represent the number of vehicles of each type and direction that crosses the bridge (these are parameters to the functions invoked by the tests we provide). For each vehicle, the main thread must spawn a new thread that executes the OneVehicle procedure, which you must implement. Your solution will be graded through code inspection to verify the correctness of the synchronization algorithms (in addition to basic functionality checks of the running code).
Makefiles when I add a new source file?
To add a .c
file, edit the top-level Makefile.build
.
Add the new file to variable dir_SRC
, where
dir is the directory where you added the file. For this
project, that means you should add it to threads_SRC or
devices_SRC. Then run make. If your new file
doesn't get
compiled, run make clean and then try again.
When you modify the top-level Makefile.build
and re-run
make, the modified
version should be automatically copied to
threads/build/Makefile
. The converse is
not true, so any changes will be lost the next time you run make
clean from the threads
directory. Unless your changes are
truly temporary, you should prefer to edit Makefile.build
.
A new .h
file does not require editing the Makefile
s.
warning: no previous prototype for `func' mean?
It means that you defined a non-static function without
preceding it by a prototype. Because non-static functions are
intended for use by other .c
files, for safety they should be
prototyped in a header file included before their definition. To fix
the problem, add a prototype in a header file that you include, or, if
the function isn't actually used by other .c
files, make it
static.
Timer interrupts occur TIMER_FREQ times per second. You can
adjust this value by editing devices/timer.h
. The default is
100 Hz.
We don't recommend changing this value, because any changes are likely to cause many of the tests to fail.
There are TIME_SLICE ticks per time slice. This macro is
declared in threads/thread.c
. The default is 4 ticks.
We don't recommend changing this value, because any changes are likely to cause many of the tests to fail.
See section 1.2.1 Testing.
pass()?
You are probably looking at a backtrace that looks something like this:
0xc0108810: debug_panic (lib/kernel/debug.c:32) 0xc010a99f: pass (tests/threads/tests.c:93) 0xc010bdd3: test_mlfqs_load_1 (...threads/mlfqs-load-1.c:33) 0xc010a8cf: run_test (tests/threads/tests.c:51) 0xc0100452: run_task (threads/init.c:283) 0xc0100536: run_actions (threads/init.c:333) 0xc01000bb: main (threads/init.c:137) |
This is just confusing output from the backtrace program. It
does not actually mean that pass() called debug_panic(). In
fact, fail() called debug_panic() (via the PANIC()
macro). GCC knows that debug_panic() does not return, because it
is declared NO_RETURN (see section E.3 Function and Parameter Attributes), so it doesn't include any code in fail() to take
control when debug_panic() returns. This means that the return
address on the stack looks like it is at the beginning of the function
that happens to follow fail() in memory, which in this case happens
to be pass().
See section E.4 Backtraces, for more information.
schedule()?
Every path into schedule() disables interrupts. They eventually
get re-enabled by the next thread to be scheduled. Consider the
possibilities: the new thread is running in switch_thread() (but
see below), which is called by schedule(), which is called by one
of a few possible functions:
thread_exit(), but we'll never switch back into such a thread, so
it's uninteresting.
thread_yield(), which immediately restores the interrupt level upon
return from schedule().
thread_block(), which is called from multiple places:
sema_down(), which restores the interrupt level before returning.
idle(), which enables interrupts with an explicit assembly STI
instruction.
wait() in devices/intq.c, whose callers are responsible for re-enabling interrupts.
There is a special case when a newly created thread runs for the first
time. Such a thread calls intr_enable() as the first action in
kernel_thread(), which is at the bottom of the call stack for every
kernel thread but the first.
Don't worry about the possibility of timer values overflowing. Timer values are expressed as signed 64-bit numbers, which at 100 ticks per second should be good for almost 2,924,712,087 years. By then, we expect Pintos to have been phased out of the OS curriculum.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |