We used resource allocators, much like the one described in the lectures, for each of the ingredients, the beer tap, cups and glasses. This simplified the way our service personnel accessed the different resources. Deadlock means that "two or more processes are each waiting for each other to release a resource" (Wikipedia). Since each service person always releases the allocator before requiring the next resource there is no risk of deadlock, meaning for example that the landlord will never hold on to the milk until the barmaid releases the coffee and vice versa. Since the processes are only competing for a single resource at a time we do have a race condition, yet no risk of deadlock. The same reasoning is valid for the cups and glasses.

The trickiest part for us was dealing with the customer behavior, especially around closing time. By analyzing the different scenarios we realized that customers could get stuck in the queue if they had ordered a beverage before closing time, however the landlord stopped servicing these orders. We therefore implemented a special behavior for these customers that allowed them to simply leave instead of queuing for infinity.

A design choice we made was having one clock belonging to the Landlord, seeing as he is the man in charge, which dictates the opening hours and when last orders should be called. We also chose to let each Customer have a clock of their own which was used for timing both their drinking as well as their time spent waiting, mainly because it made more sense for them to keep these times themselves instead of relying on the landlord's clock.

The only modifications of the supplied classes was that we removed the printing from Clock, since we consider that to be our responsibility.