mission:
complete part a and part b.
part a:
write an interrupt handler for the hardware timer to provide preemptive scheduling in the rudimentary 'operating system' we've developed over the semester.part b.difficulty: low.
there is a ready made API to handle the timer. no big deal. my hardware programming class from last semester required me to learn all about interrupt driven routines. yup. been there. done that. i learned how to program the timer in c and assembly.
objective:
make the timer send an interrupt every ten miscroseconds. call the tiny OS's scheduler to give each 'process' alternating access to the CPU for roughly equal shares of time.
think: several user programs running at once.
the OS must efficiently divide the CPU's resources between these programs. while the CPU can only perform one 'instruction' at a time, it can process a lot of them in 40 microseconds. the 'OS' we have built is so very very rudimentary. the department has a repository of useful example code for this kind of assignment. all of it is well-documented, so this assignment was easy.
_totally_. *not*. like. the. real. world.
there are two processes. one process produces what the other process consumes.difficulty: [expletive]!?*_!!
objective:
synchronize them.
the producer puts things into a 'bag' and the consumer takes them out. the producer can never put too many things into the bag because the bag has a fixed size. the consumer can never take anything from an empty bag.
the producer and the consumer can never be allowed to have access to the bag at the same time.
the semaphore is an algorithm that makes sure all this happens. this assignment required an understanding of the scheduler and the not so well documented API we've built for it in previous assignments. it was absolute and utter hell. very subtle and difficult to find bugs.
no, sam i am, i do not wish to write about the semaphore. i simply cannot think about these things called semaphores anymore.
No comments:
Post a Comment