EZ-Pass system -- Concurrency project

CISC 280 Program Development Techniques

Reading: SICP (Structure and Interpretation of Computer Programs), Section 3.4

This project builds from the module J homework about ticket sales. Code to start from is given at ~saunders/280/ezpass.scm

The project is due at start of lab 14 May 01:

Modify the ticket seller program to be a EZ-Pass system. In place of ticket sellers we have EZ-Pass code readers. Instead of wanting a ticket to an event, customers are passing through an EZ-Pass booth on the highway and are implicitly ordering the right to drive on the toll road or or over the bridge. Instead of tracking how many seats remain to be sold, the system must track the status of the EZ-Pass account of each vehicle. Also it must keep a record of which vehicles passed through each booth. In the end each booth prints out it's list of vehicles, the number of them, and the total toll money collected. When asked, accounts print a statement showing all the booths the car passed through during a specified period of time and the resulting balance in the account.

The booths operate as separate threads running in parallel. Thus it is important that functions they use are "thread-safe". This simply means that functions must be serialized if they involve sequences of instructions that, for consistency of data, must not be interleaved with instructions from other threads.

Specifically, do the following:

  • Replace (make-ticket-seller) with (make-EZ-Pass-booth id-of-booth toll-amount)

    The EZ-Pass-booth created by this function charges each passing vehicle toll-amount dollars by updating the account record for that vehicle. The function (customer-order), aka (scan-vehicle), returns a number, call it ezpass-acct-id, which is the id of the vehicle passing the booth. The EZ-Pass-booth is then responsible for updating the account record for that vehicle's ezpass-acct-id. as well as it's own record of vehicles passing through the booth.

    The booths also have a capability to report a summary of the activity at the booth. At the end of time, the booth prints the summary showing it's name, total toll money collected, total number of passing cars, and finally a list of all the cars that passed.

    Like the ticket sellers, the ezpass-booths operate concurrently in separate threads of execution. Because some ezpass holders may have several vehicles on their account and because all these vehicles have the same ezpass-acct-id, it may happen that the booths are trying to update the same account concurrently. Thus it is required to serialize the core accesses to each account, treating the accounts as shared data, much as the ticket sellers treated the *SEATS* variable.

  • Define (make-account balance account-holder-name) which returns a new ezpass account. An ezpass account is to be a dispatch procedure which accepts various messages. For example, given (define my-EZacct (make-account 50 'me)) the call 
    ((my-EZacct 'debit) date/time toll-amount booth-id)
    will deduct toll-amount from my balance and will add a transaction record consisting of day/time, toll-amount, and booth-id to it's list of transactions. 
    ((my-EZacct 'statement) start-date/time end-date/time)
    will display the account holder's name, the balance at end-date/time, and the list of tolls charged during the period from start-date/time through end-date/time.

    Remark: In a full system other messages would be handled to do things like add amounts to the balance, to finally erase really old toll transaction records from the system, to close accounts, etc. We will save implementing these functions for later, much later. Let next year's 280 students do it, say.

    Partially implemented code for this project is in file
    ~saunders/280/ezpass.scm
    The code runs as given, but the results are not very interesting because key functions are just shells of what they should be. Start with that code and evolve it into a correct system. Comments are provided suggesting what is needed (and roughly where) in order to have the system operate as described above. Note that it is left up to you to make some of the detailed decisions (specifications) about how the system performs. For instance the specific form in which toll booths and customer accounts store their information is left up to you. Also just how and when they compute the needed information to give the reports (account statements, booth summaries) is up to you, as is the precise of the form of the reports. As to form, it is sufficient that the displayed information includes the specified items).