rpocase/comp3510 — pull request #2 by mhd0003 (2014-03-15 07:41:34+00:00)
Title: Rpocase

**Dr. Biaz: "Currently, you display them, but you do not "serve" them."**
I think he is suggesting that we need to display them *and* serve them, which sounds more like FQS than RR w/ Int. I think for Lab 3, we will deal with priorities. (ew)

This adds a simple queue. When events are displayed, they are also saved in the queue, which becomes part of the urgent steps. Control() uses the queue to find the next event that occurred, maybe a really long time ago, but hasn't been Server()'d yet.
I think that addresses what Dr. Biaz said because:
- Events get enqueued and displayed if the interrupt catches them on time
- Control() calls Server() on *all* events in the queue, unless program ends early

There's still improvements that could be made, but when I let both versions run until they called Server() on event ID 28 or so...
- avg response dropped 0.432s to 0.002s
- events missed dropped from 91-92 to 71-73
- running time increased from ~58s to ~90s -- but 20 more events also had to get processed

But both **still** took about 20 seconds for Server() to respond the first time. So we'd miss 20% of events, because the program ends pretty quickly after the 100th event is thrown. The results from above are from our worst run in Lab 1 -- 2 2 90 0 -- where we missed 45%.

Let me know what you guys think. I might not be able to respond tomorrow, which is why I'm trying to explain everything now.