This problem focuses on the input side of a window manager! Assume that we have two asynchronous serial input devices: When a key is hit on the keyboard, the corresponding character is placed in the keyboard-data register and a keyboard interrupt is requested. When the mouse moves or the mouse button is pressed, a code (up, down, left, right, click) is placed in the mouse-data-register, and a mouse-interrupt is requested.
Assume that the key-codes for characters on the keyboard are distinct from the codes used for up, down, left and right, and assume that the specification of the window manager states that there shall be a distinct input queue for each window. Whenever the mouse pointer is in that window, all mouse motion and all keypresses should be enqueued in that window. When the mouse pointer enters or exits a window, a special code, enter-window or exit-window, should be placed in that window's input queue, and the bytes immediately following the enter-window code always give the coordinates (relative to the origin of that window's) of the mouse at the time it entered the window.
Assume that the window manager has one process dedicated to input management. This process has access to the window manager's database of window descriptions and it is responsible for maintaining the current coordinates of the mouse on the screen, plotting the cursor on the screen, and distributing input to the input queues belonging to the various users.
Part A: Assuming that all interprocess synchronization and synchronization between user processes and input interrupt service routines is done using semaphores, what semaphores does the above description imply!
Note: You may want to defer the final draft of your answer to this part of the question until you've answered part B. Your answer to part B will require an answer to part A, but it will also test the correctness of your answer to part A!
Part B: Outline the code for the window manager input process, using high level pseudocode that does not mention any details that were not given above.
mouse_input_interrupt_service_routine:
d = mouse_data_register
enqueue( d, mouse_input_queue )
signal( mouse_input_data )
return
Note that this description assumed a few things: First, it assumed that entry
to the interrupt service routine disabled interrupts and saved the CPU state;
second, it assumed that the test of the moust data
register caused the mouse interrupt request to be retracted, and third, it
assumed that the return from interrupt re-enabled interrupts and restored
the CPU state.
Part A: Can we use the same implementation of wait and signal in an interrupt service routine as we use in user programs? For example, can the uniprocessor implementation of wait and signal given at the end of the notes for Lecture 3 be used within the above example interrupt service routine?
Part B: Consider an asynchronous output interrupt service routine, for example, a routine that processes output directed to a modem. The hardware interface has a data register, and it begins to output a character as soon as that character is placed in the data register. When the output of the character in the data register is complete, the interface hardware requests an output- complete interrupt. The output interrupt handler must synchronize with the process producing data to be output; as was done with input, a FIFO queue can be used to buffer the data between user and interrupt handler.
Explain why it is not possible to use a semaphore to provide synchronization between the user and the output interrupt handler. Specifically, explain why the interrupt handler cannot use wait to block itself until the user uses signal to indicate that data is available.
The Problem: Discuss the problems you might encounter in trying to use the SIGALRM signal to cause preemptive context switching within our thread manager.