This repository has been archived by the owner on Jul 10, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
DesignDoc.txt~
138 lines (88 loc) · 5.31 KB
/
DesignDoc.txt~
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
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; //List of threads waiting to be woken up
thread.h:
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:
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.
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 ----
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
===================
---- 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?