Modifications, assumptions and design decisions
===============================================

The implementation follows the instuctions given, with the minor
modification that some entities (most notably the Landlord and the
Customers) have a separate internal clock for timing purposes.

A number of assumptions have also been made:

* All times are set in a sensible manner (drinking time is less than
assistant interval and so on)
* If a customer is refused at the bar, he'll go home

The glasses have been implemented using op-channels for emulating
semaphores.
They also contain information about how many items are left (receive 
"takes" an item and send puts it back), which means we don't have to
keep track of this ourselves.

We also made the decision not to care about customers putting down
glasses during cleaning - the worst-case scenario (since the `inni`
statement is mutexed) is that we have to clean the table one more time.

The order queue is an operation of the `Lab2` class, which can be seen
as a general "bar" class (since it contains the clock and tables). The
Barmaid and Landord receive from this operation. This is standard
message passing.

Deadlocks
=========

Deadlocks can present themselves at several points in this assignment,
but the two most critical involve the cupboard. The first one,
concerning ingredients, is solved by careful ordering: If we always
take e.g. the milk first, then coffee, we won't reach a deadlock. A
deadlock is only reached if e.g. the Barmaid takes milk, coffe and the
Landlord takes coffee, milk (or similar).
