JMU
Programming Assignment 6


1 Summary

zmedia is very happy with the zplayer (and bookz_player) from PA5. However, you have discovered some aspects of your current implementation that you are unhappy with. So, you are going to refactor your code.

2 The Problem with the Current Implementation

The system currently claims to use an event-driven architecture, however, that is only loosely true. In particular (as you recall from the reading early in the semester), an event-driven architecture makes use of an event queue, and your implementation does not. Instead, when an event is generated, the event receiver is "informed" directly using a function call (i.e., handle_event()).

This approach, while simpler than using an event queue, could cause a serious problem. In particular, consider the Loading state. Things start fine -- in response to an 'l' character, the handle_event() function calls the entry_to() function. However, consider what happens when the user enters a character that doesn't correspond to an existing .bookz file. The system calls handle_event() passing it an 'F' character, which, in turn, results in a recursive call back to entry_to(). Further, if the user continues to enter characters that don't correspond to an existing .bookz file, the recursion will get deeper and deeper.

While these calls will "unwind" properly, it is possible for the stack to overflow if the recursion gets too deep. Hence, this is a defect that must be corrected.

3 Specifications/Constraints

Since this is a refactoring of existing code, the functionality of the zplayer and bookz_player must remain unchanged.

Your refactored code must satisfy the following specifications/constraints.

  1. The system must use a pipe/FIFO for the event queue. Event generators must write a single character at a time (representing an event) into the "write end" and event receivers must read a single character character at a time from the "read end".
  2. The system must have one process that plays only the role of event generator. Specifically, it must read a character at a time from standard in and write that character to the "write end" of the pipe/FIFO.
  3. The system must have one process (executing the implementation of the state model) that plays both the role of event receiver and event generator.
    1. As an event receiver, it must read a character from the "read end" of the pipe/FIFO and pass it to the handle_event() method.
    2. As an event generator it must, when appropriate (e.g., for the 'F' and 'S' events that are generated in the Loading state), write a single character at a time to the "write end" of the pipe/FIFO.
  4. The system must use one or more semaphores to control access to the Interaction Terminal (IT). It may also one or more semaphores to control access to the event queue.

Of course, for obvious reasons, the bookz_player must still execute in its own process.

4 Submission

The .zip file you submit must be named pa6.zip. In addition to the source code and makefile, the .zip file must contain four screenshots that capture the state of the OS at different times.

Each screenshot must capture the following three things.

  1. The relevant current processes.
  2. The relevant current semaphores.
  3. The relavant current pipes/FIFOs.

You must submit four screenshots in total.

  1. before.png must be taken before you run zplayer.
  2. ready.png must be taken when zplayer is in the Ready state.
  3. playing.png must be taken when zplayer is in the Playing state.
  4. after.png must be taken after zplayer has terminated.

You must not submit any data files.

5 Help and Hints

You have had very little freedom in previous assignments. For this assignment you have considerably more latitude, making it considerably more difficult. Given this, you should allocate more time for this assignment, and you should spend more time thinking before you start typing. Specifically, you should give careful consideration to each of the following points/issues.

5.1 Pipe of FIFO?

You may use either a pipe or a FIFO, but you should think about which would be best and/or simplest.

5.2 Processes

  1. When a bookz is playing, your system must have at least three active processes. You may use additional processes, but you should think carefully about the implications before you decide to do so.
  2. You may call exec() after you call fork() however it is not required. You should think carefully about the implications of both.

5.3 Semaphores

You should think carefully about how to use semaphores.

If you search the WWW you will find many discussions of how to use semaphores to control access to an event queue. However, those event queues are generally far more flexible than is needed here (and they typically don't make use of a pipe/FIFO).

Also, you may be inclined to think that the mutual exclusion property is an essential aspect of the protocol you must develop. This may or may not be the case -- you may need to be more concerned with sequencing than mutual exclusion.

Finally, remember that, unlike the examples from lecture, at least one of the processes in this assignment (i.e., the process that the state model executes in) is complicated and the code spans multiple files. So, make sure you understand what code is executing in what process.

Copyright 2017