Permalink
Browse files

final alarm updates to DesignDoc.txt

  • Loading branch information...
1 parent 11d65fe commit 93e92c2ca9a36f87a642c5a9eab715cdbc3b7e67 @Frankencelery Frankencelery committed Oct 5, 2012
Showing with 156 additions and 19 deletions.
  1. +16 −14 DesignDoc.txt
  2. +136 −0 DesignDoc.txt~
  3. +4 −5 src/devices/timer.c~
View
30 DesignDoc.txt
@@ -18,41 +18,43 @@ None
---- DATA STRUCTURES ----
timer.c:
-static struct list thread_list;
+static struct list thread_list; //List of threads waiting to be woken up
thread.h:
-int64_t wakeup_time;
-struct semaphore sema_wakeup;
->> A1: Copy here the declaration of each new or changed `struct' or
->> `struct' member, global or static variable, `typedef', or
->> enumeration. Identify the purpose of each in 25 words or less.
-
+int64_t wakeup_time; //Time that thread is to be woken up (in ticks)
+struct semaphore sema_wakeup; //Thread semaphore to put thread to sleep and wake up
+struct list_elem timer_list_elem; //List element to attach to thread_list
---- ALGORITHMS ----
->> A2: Briefly describe what happens in a call to your timer_sleep(),
->> including the effects of the timer interrupt handler.
+A2:
+ Within timer_sleep, the number of ticks is captured into a local variable, and the current thread is assigned to a local variable "t". "t"'s wakeup time is then set to the current # of ticks plus the requested sleep time.
->> A3: What steps are taken to minimize the amount of time spent in
->> the timer interrupt handler?
+ Interupts are then disabled, and "t" is inserted into the list of sleeping threads (thread_list). Interupts are re-enabled, and the thread's semaphore is lowered, yielding the thread to the next one in the queue.
+ If the timer interupt handler is called, as long as the thread_list is not being modified, it will have no effect on the operation. The timer_interupt increments the number of system ticks, then checks to see if any threads are ready to be woken up. If the list is not empty, timer_interupt loops through the list, waking up all threads whose wakeup_time is <= to the current time. These threads are then removed from the list.
+A3:
+ Once the ticks are incremented, the handler checks to see if any threads are asleep, if not it exits immeditely. If the list is not empty, the handler checks to see if the first element is ready to be woken up, if not it exits. Since the elements are sorted by time, the first element will always be the one that is ready to be woken up next.
+
---- SYNCHRONIZATION ----
>> A4: How are race conditions avoided when multiple threads call
>> timer_sleep() simultaneously?
+>> A4:
+ The only time a global variable is updated, interupts are disabled. All other actions can be safely interupted, as only local variables will be updated.
>> A5: How are race conditions avoided when a timer interrupt occurs
>> during a call to timer_sleep()?
+ Race conditions are avoided in the same way as A4 above, by protecting all code that updates global variables. However, there is a possibility of a race condition if timer_interupt runs between the list_insert and sema_down. Since, though, sema_down will yield the thread to the next availble thread, instablility will be introduced into the system if interupts are disabled when sema_down is called. This error will only be possible if timer_sleep(0) is called, though, which is unlikely.
+
---- RATIONALE ----
->> A6: Why did you choose this design? In what ways is it superior to
->> other designs that you considered?
-
+This design has little busy waiting, and efficently sorts the threads for the interupt handler function. Unlike other implementations, it allows very little room for race conditions, with the exception of timer_sleep(0) above.
PRIORITY SCHEDULING
View
136 DesignDoc.txt~
@@ -0,0 +1,136 @@
+CIS 520 - Programming Project #1
+
+---- GROUP ----
+
+Benjamin Kuestersteffen <bkuester@ksu.edu
+<Grant>
+
+...
+
+---- PRELIMINARIES ----
+
+None
+
+
+ ALARM CLOCK
+ ===========
+
+---- DATA STRUCTURES ----
+
+timer.c:
+static struct list thread_list;
+
+thread.h:
+int64_t wakeup_time;
+struct semaphore sema_wakeup;
+>> A1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration. Identify the purpose of each in 25 words or less.
+
+
+
+---- ALGORITHMS ----
+
+>> A2: Briefly describe what happens in a call to your timer_sleep(),
+>> including the effects of the timer interrupt handler.
+
+>> A3: What steps are taken to minimize the amount of time spent in
+>> the timer interrupt handler?
+
+
+---- SYNCHRONIZATION ----
+
+>> A4: How are race conditions avoided when multiple threads call
+>> timer_sleep() simultaneously?
+
+
+>> A5: How are race conditions avoided when a timer interrupt occurs
+>> during a call to timer_sleep()?
+
+
+---- RATIONALE ----
+
+>> A6: Why did you choose this design? In what ways is it superior to
+>> other designs that you considered?
+
+
+
+ PRIORITY SCHEDULING
+ ===================
+
+---- DATA STRUCTURES ----
+
+>> B1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration. Identify the purpose of each in 25 words or less.
+
+>> B2: Explain the data structure used to track priority donation.
+
+
+---- ALGORITHMS ----
+
+>> B3: How do you ensure that the highest priority thread waiting for
+>> a lock, semaphore, or condition variable wakes up first?
+
+>> B4: Describe the sequence of events when a call to lock_acquire()
+>> causes a priority donation. How is nested donation handled?
+
+>> B5: Describe the sequence of events when lock_release() is called
+>> on a lock that a higher-priority thread is waiting for.
+
+---- SYNCHRONIZATION ----
+
+>> B6: Describe a potential race in thread_set_priority() and explain
+>> how your implementation avoids it. Can you use a lock to avoid
+>> this race?
+
+---- RATIONALE ----
+
+>> B7: Why did you choose this design? In what ways is it superior to
+>> another design you considered?
+
+
+ ADVANCED SCHEDULER [EXTRA CREDIT]
+ =================================
+
+---- DATA STRUCTURES ----
+
+>> C1: Copy here the declaration of each new or changed `struct' or
+>> `struct' member, global or static variable, `typedef', or
+>> enumeration. Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> C2: Suppose threads A, B, and C have nice values 0, 1, and 2. Each
+>> has a recent_cpu value of 0. Fill in the table below showing the
+>> scheduling decision and the priority and recent_cpu values for each
+>> thread after each given number of timer ticks:
+
+timer recent_cpu priority thread
+ticks A B C A B C to run
+----- -- -- -- -- -- -- ------
+ 0
+ 4
+ 8
+12
+16
+20
+24
+28
+32
+36
+
+>> C3: Did any ambiguities in the scheduler specification make values
+>> in the table uncertain? If so, what rule did you use to resolve
+>> them? Does this match the behavior of your scheduler?
+
+>> C4: How is the way you divided the cost of scheduling between code
+>> inside and outside interrupt context likely to affect performance?
+
+---- RATIONALE ----
+
+>> C5: Briefly critique your design, pointing out advantages and
+>> disadvantages in your design choices. If you were to have extra
+>> time to work on this part of the project, how might you choose to
+>> refine or improve your design?
+
View
9 src/devices/timer.c~
@@ -31,11 +31,10 @@ static void real_time_sleep (int64_t num, int32_t denom);
static void real_time_delay (int64_t num, int32_t denom);
static struct list thread_list;
-static bool compare_threads_by_wakeup_time(struct list_elem *a_, struct list_elem *b_, void *aux UNUSED)
+static bool compare_threads_by_wakeup_time(const struct list_elem *a_, const struct list_elem *b_, void *aux UNUSED)
{
const struct thread *a = list_entry(a_, struct thread, timer_list_elem);
const struct thread *b = list_entry(b_, struct thread, timer_list_elem);
- printf("We sorted\n");
return a->wakeup_time < b->wakeup_time;
}
@@ -99,15 +98,15 @@ timer_elapsed (int64_t then)
void
timer_sleep (int64_t ticks)
{
- printf("We got into sleep!\n");
+// printf("We got into sleep!\n");
int64_t start = timer_ticks ();
struct thread *t = thread_current();
t->wakeup_time = ticks + start;
intr_disable();
list_insert_ordered(&thread_list, &t->timer_list_elem, compare_threads_by_wakeup_time,NULL);
- intr_enable();
sema_down(&t->sema_wakeup);
- printf("We got woken up\n");
+ intr_enable();
+// printf("We got woken up\n");
/*while (timer_elapsed (start) < ticks)
thread_yield ();*/
}

0 comments on commit 93e92c2

Please sign in to comment.