Q: For the cat and mice problem, is it okay for us to use some global variables such as counters along with semaphores/condition variables to implement the solution? A: Yes, it is okay. -------------------------------------------------------------------------------- Q: Signal and broadcast's descriptions don't say anything about the lock, so why is the lock passed to them as an argument? I currently have a working implementation of CVs which does not use the lock argument. A: As a precaution, signal and broadcast can check that the lock passed to them has been acquired before these functions are called (they should not be called outside a critical section, or else races are possible). -------------------------------------------------------------------------------- Q: When we run our program for cat and mouse, the value for count in some of our semaphores is corrupted in a context switch. We end up with count = -559038737, which means that when P() is called on the corrupted semaphore, it fails the assert() call, resulting in scheduler_killall() being called. Another weird thing is that although we have our random number generator set to "seed=1", this happens to different semaphores each time we run the kernel. What could be causing this? A: Check whether the contents of sem are correct after a context switch. We suspect that the entire sem data structure (e.g., name field) is corrupted. You will need to use a debugger to step through your code, in particular the context switch code, to see what is causing the corruption. -------------------------------------------------------------------------------- Q: We were using gdb to step through context switch code, but even though we were using the 's' command to step through the lines, the debugger still skipped over the context switch code. Is there a way to make gdb step through the context switch code itself? A: Use stepi, which steps machine instructions (rather than source code lines) at a time. Tip #6, gdb.html -------------------------------------------------------------------------------- Q: Are we allowed to disable/enable interrupts as part of our solution for catsem() and mousesem()? A: No. Please use only the lock/semaphore/monitor synchronization primitives. While these threads are currently running in the kernel, a solution using these synchronization primitives (implemented as system calls) will work at the user level also. A solution using interrupts will not work at the user level. -------------------------------------------------------------------------------- Q: The "Cardirection" variable--does it refer to the direction that the car is coming from or going towards? For example, if the cardirection is 0 (N), does it mean that the car is going from north (travelling towards south) or going towards south (coming from north)? A: The "cardirection" refers to the direction where the car is coming from. In your example, cardirection of 0 means the car is coming from north and going south. -------------------------------------------------------------------------------- Q: Are cars prohibited to enter the intersection if any one of the required squares in the intersection is occupied at the time the cars approach the intersection? Or do cars go on a square by square basis? For example, a car is approaching from north, going straight. At the time the south west square is occupied but northwest is free. Does this car enter the intersection or wait for the previous car to clear the intersection completely? Q: Multiple cars are allowed in the intersection as long as they are not in one of the four squares at the same time. -------------------------------------------------------------------------------- Q: We understood the restriction on passing to be only in the intersection, i.e., cars only announce that they are approaching the intersection immediately before they attempt to acquire the first intersection lock. Is this correct or are the cars required to queue in the order they created? A: Cars must queue in the order created when approaching from each direction. This is the distinction between "approaching" and "region1" in the first argument of the message() function. -------------------------------------------------------------------------------- Q: Car 1 enters from S side and turns left, while Car 2 enters from S side and turns right. Our current implementation will mean Car 2 may exit before Car 1 exits. Is that fine? Since they are both heading to a different direction. A: Yes, the exit in this order is fine. However, if Car 1 approaches the intersection before Car 2, then Car 1 should enter the intersection before Car 2, even if they are headed in different directions. -------------------------------------------------------------------------------- Q: What if we do not queue according to direction of approach but rather direction of compatible destinations (e.g put everyone who wants to turn left in a single queue) A: That is fine as long as the order of approaching and entering the regions is maintained from each direction. -------------------------------------------------------------------------------- Q: Does this mean that, for example, if cars 1,2,3,4 are created and assigned as coming from the north, then we need to enforce that they approach the intersection in that order? What if, depending on how threads are woken and queued, you have a situation like: car 2 approaches intersection, car 2 enters intersection, car 4 approaches intersection, car 4 enters intersection, car 1 approaches, enters, car 3 approaches, enters. In this scenario, none of the cars are passing each other since they approach and enter consecutively, but is this incorrect since they are not in order of 1-4 (which would correspond to the order they were created in)? A: That is fine. The ordering requirement is not on the creation but on approaching and entering the regions. -------------------------------------------------------------------------------- Q: I was wondering, if the implementation of our solution has to be an "elegant" solution, because we have an implementation working, and it appears to be working properly. However, this solution uses locks heavily, (and right now we don't see an easier solution). So as long as it is logically sound, and uses the Synchronization primitives properly, it should be an acceptable solution, right? A: As long as you can explain your solution. -------------------------------------------------------------------------------- Q: Is it up to us to determine how complex the intersection is? The lab only specifies that there must be an "improvement" of the intersection but not by how much. It it okay if our implementation is only "slightly" better than the four-way stop? A: We have given you freedom to choose your implementation, even if it is only slightly better. However, make sure that you can explain why it is better. --------------------------------------------------------------------------------