- - Godmar:
-
- >> 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?
-
- My guess is that you're referring to the fact the scheduler
- specification does not prescribe any order in which the priorities of
- all threads are updated, so if multiple threads end up with the same
- priority, it doesn't say which one to pick. ("round-robin" order
- would not apply here.)
-
- Is that correct?
-
- - Godmar:
-
- One of my groups implemented priority donation with these data
- structures in synch.cc:
- ---
- struct value
- {
- struct list_elem elem; /* List element. */
- int value; /* Item value. */
- };
-
- static struct value values[10];
- static int start = 10;
- static int numNest = 0;
- ---
- In their implementation, the "elem" field in their "struct value" is
- not even used.
-
- The sad part is that they've passed all tests that are currently in
- the Pintos base with this implementation. (They do fail the additional
- tests I added priority-donate-sema & priority-donate-multiple2.)
-
- Another group managed to pass all tests with this construct:
- ---
- struct lock
- {
- struct thread *holder; /* Thread holding lock (for debugging). */
- struct semaphore semaphore; /* Binary semaphore controlling access. */
- //*************************************
- int pri_prev;
- int pri_delta; //Used for Priority Donation
- /**************************************************/
- };
- ---
- where "pri_delta" keeps track of "priority deltas." They even pass
- priority-donate-multiple2.
-
- I think we'll need a test where a larger number of threads & locks
- simultaneously exercise priority donation to weed out those
- implementations.
-
- It may also be a good idea to use non-constant deltas for the low,
- medium, and high priority threads in the tests - otherwise, adding a
- "priority delta" might give - by coincidence - the proper priority for
- a thread.
-