Jun. 2nd, 2009
OS project conclusion
Jun. 2nd, 2009 01:08 amSo, project 3: Not a catastrophe. Certainly not a success, but not a catastrophe.
Unfortunately, the thing about project 3 is that it kept coming down to project 2. (We eventually swapped out Youlian's malloc() and free() for Blume's, when something (we still have no idea what) sent Youlian's malloc() into an infinite loop. (My malloc() and free(), meanwhile, just didn't work as well as Youlian's.)) A large part of project 3 was modifying your threading code so it would work while allowing individual threads to block (on a channel) - previously only whole tasks[0] could block (on a mutex or condition variable[3]).
The display server[4], the timer server, the button server? We're pretty certain they all work - assuming channels do. And unfortunately we were not able to work all the kinks out of the task/channel interaction. Where by "we were not able to work all the kinks out" I mean "everything worked fine at first but eventually failed given enough time, though at least system crashes were a lot rarer". (The bug we were trying to work out when time came to turn it in was a system crash that came about because malloc() somehow clobbered the stack. And this was Blume's "reference" malloc(), mind you, not either of ours.) Channels and threads within a single task seemed to work fine, but a recurring problem seemed to be tasks or threads vanishing into thin air - an infinite loop would just go away, as if it had finished, or the system would decide quite early (e.g. while one thread was supposed to be looping infinitely) that hey, all the tasks are done, time to sleep, or that, hey, all the threads are blocked, time to wait for an interrupt to unblock one[5].
I'm tempted to say that our scheduler wasn't fair, except it was just a simple queue. You get put on the queue, you *are* going to get scheduled[6]. Unless all your threads are blocked, I guess. Maybe that was the problem - my procedure for handling the all-threads-blocked case screwing up the fairness of the queue? No, that doesn't explain the vanishing of threads that never should have been blocking at all...
Well, it's done. No more OS work, no more Algebra homework, just a pset and a final for Manifolds. Gives me time to find housing, I guess. :P
-Harry
[0]Like processes, I guess, but without most of what makes processes processes. Instead, the distinction here was that tasks were preemptively scheduled, while threads within a task were cooperatively scheduled.
[3]Am I the only one who was quite confused for a while by the name "condition variable"? There's no actual variable! (Well, I mean I know I'm not, Youlian certainly was too... I guess really I just mean Blume could have explained it better. :P )
[4]An actual RCX brick is very limited in its display; however, for this project, our virtual RCX bricks had an extra display, called the "ticker", that could display up to 32 characters at a time. Its availability made debugging project 3, while still a real pain[7], a lot easier than debugging 1 and 2... (well, it was always there, but we weren't given macros to control it then).
[5]Which could only actually happen if someone pressed one of the RCX's buttons. But in fact, one of the infinite-loop server threads Youlian wrote for handling the timer should never block at all! It sent messages, which can require blocking, as we were doing synchronous message-passing, but this particular thread could only send messages to threads already waiting for one. (I mean, barring horrible things occurring. But the problem wasn't it blocking but it apparently vanishing.)
[6]I mean, you could also not be on the queue because you're blocked, but I'm pretty sure we handled the unblocking of tasks...
[7]And not in the sense that debugging is always a pain, but in the "You have something like a line debugger, but it sucks, and oh also even your ability to write debugging code is quite limited" sense.
Unfortunately, the thing about project 3 is that it kept coming down to project 2. (We eventually swapped out Youlian's malloc() and free() for Blume's, when something (we still have no idea what) sent Youlian's malloc() into an infinite loop. (My malloc() and free(), meanwhile, just didn't work as well as Youlian's.)) A large part of project 3 was modifying your threading code so it would work while allowing individual threads to block (on a channel) - previously only whole tasks[0] could block (on a mutex or condition variable[3]).
The display server[4], the timer server, the button server? We're pretty certain they all work - assuming channels do. And unfortunately we were not able to work all the kinks out of the task/channel interaction. Where by "we were not able to work all the kinks out" I mean "everything worked fine at first but eventually failed given enough time, though at least system crashes were a lot rarer". (The bug we were trying to work out when time came to turn it in was a system crash that came about because malloc() somehow clobbered the stack. And this was Blume's "reference" malloc(), mind you, not either of ours.) Channels and threads within a single task seemed to work fine, but a recurring problem seemed to be tasks or threads vanishing into thin air - an infinite loop would just go away, as if it had finished, or the system would decide quite early (e.g. while one thread was supposed to be looping infinitely) that hey, all the tasks are done, time to sleep, or that, hey, all the threads are blocked, time to wait for an interrupt to unblock one[5].
I'm tempted to say that our scheduler wasn't fair, except it was just a simple queue. You get put on the queue, you *are* going to get scheduled[6]. Unless all your threads are blocked, I guess. Maybe that was the problem - my procedure for handling the all-threads-blocked case screwing up the fairness of the queue? No, that doesn't explain the vanishing of threads that never should have been blocking at all...
Well, it's done. No more OS work, no more Algebra homework, just a pset and a final for Manifolds. Gives me time to find housing, I guess. :P
-Harry
[0]Like processes, I guess, but without most of what makes processes processes. Instead, the distinction here was that tasks were preemptively scheduled, while threads within a task were cooperatively scheduled.
[3]Am I the only one who was quite confused for a while by the name "condition variable"? There's no actual variable! (Well, I mean I know I'm not, Youlian certainly was too... I guess really I just mean Blume could have explained it better. :P )
[4]An actual RCX brick is very limited in its display; however, for this project, our virtual RCX bricks had an extra display, called the "ticker", that could display up to 32 characters at a time. Its availability made debugging project 3, while still a real pain[7], a lot easier than debugging 1 and 2... (well, it was always there, but we weren't given macros to control it then).
[5]Which could only actually happen if someone pressed one of the RCX's buttons. But in fact, one of the infinite-loop server threads Youlian wrote for handling the timer should never block at all! It sent messages, which can require blocking, as we were doing synchronous message-passing, but this particular thread could only send messages to threads already waiting for one. (I mean, barring horrible things occurring. But the problem wasn't it blocking but it apparently vanishing.)
[6]I mean, you could also not be on the queue because you're blocked, but I'm pretty sure we handled the unblocking of tasks...
[7]And not in the sense that debugging is always a pain, but in the "You have something like a line debugger, but it sucks, and oh also even your ability to write debugging code is quite limited" sense.