/**********************************************
* Please DO NOT MODIFY the format of this file
**********************************************/
/*************************
* Team Info & Time spent
*************************/
Name1: Glenn Rivkees
NetId1: ghr4
Time spent: 10 hours
Name2: Zach Michaelov// Edit this accordingly
NetId2: zgm3 // Edit
Time spent: 14 hours // Edit
Name3: Full Name // Edit this accordingly
NetId3: fn // Edit
Time spent: 10 hours // Edit
/******************
* Files to submit
******************/
lab3.jar // An executable jar including all the source files and test cases.
README // This file filled with the lab implementation details
Elevator.input // You can submit a sample input and log file
Elevator.log // corresponding to the input but Elevator.log should be
// auto-generated on execution of jar file
/************************
* Implementation details
*************************/
/*
* This section should contain the implementation details and a overview of the
* results.
* You are required to provide a good README document including the
* implementation details. In particular, you can use pseudocode to describe
* your implementation details where necessary. However that does not mean to
* copy/paste your C code. Specifically, explain the synchronization primities
* used in implmenting the elevator, scheduling choices used, how the capacity
* constraint is handled, and how the mulitple elevators are supported. Also,
* explain how to run the test cases for your EventBarrier and Elevator and how
* to interpret the results. Check the README.OUTPUTFORMAT for the acceptable
* input/output format for the elevator. Expect the design and implementation
* details to be at most 2-3 pages. A plain textfile is encouraged. However, a
* pdf is acceptable. No other forms are permitted.
* In case of lab is limited in some functionality, you should provide the
* details to maximize your partial credit.
* */
=== 1: Event Barrier ===
Event Barrier was implemented using Java monitors. All of the synchronized
functions use the Java "synchronized" keyword to ensure locking is enforced
on the function calls and competing functions do not occur at the same time.
Additionally, the "wait, notify" paradigm is used so that the threads wait
when the arrive until an event is raised and a "notify all" is given. Then,
the raise function waits until all threads have completed. The last thread
to complete notifies the Controller, which then ends the raised event. In
addition to the locking primitives, a boolean is used to track whether an
event is currently raised, and the number of threads waiting or currently
executing. These variables are secured by the general synchronized lock
that is on the functions.
Finally, to test this system, decorators were used to wrap the EventBarrier
and implement Runnable with functions needed so the thread acted as a Controller
or a "Minstrel". This allowed for easy testing of the EventBarrier.
=== 2. Elevator ===
Part 1.
The Elevator was implemented using the EventBarrier implementation from the previous part of the lab.
Each floor in the building is represented by an EventBarrier. When a rider requests a floor, they
call arrive() on the EventBarrier for the floor requested. When the elevator visits a floor, the current floor
variable is updated and the doors are opened (OpenDoors()). OpenDoors() calls raise() on the EventBarrier for that floor.
This allows waiting riders to Enter() and Exit() the elevator. on each call to Enter() and Exit() we call complete() on
the EventBarrier. In this sense, each rider knows whether they are getting off or on, and the EventBarrier is only
concerned how many people need move before it can close the doors. OpenDoors() will block until the expected number
of completes are called. We use an integer and 2 lists to keep track of the current floor, the EventBarriers, and
the requested floors. In the interest of reduced complexity and avoiding rider starvation, we process requests on a
first come, first serve basis.
Part 2.
To add the functionality for elevator capacity, we introduce an AtomicInteger to keep track of the number of Riders in
the elevator at any given time. When Rider attempts to enter the elevator, we check to see if this value is less than
the max capacity for the elevator. If it is not, we increment the integer and proceed as before, and return true. If we
have reached the max capacity, then we return false. If a Rider sees Enter() return false, they simply request another
elevator. To test this, we set the capacity to be really small (e.g. 2), and then checked on each ClosedDoors() call
how many riders were in the elevator. All riders were eventually serviced as in Part 1, it just took longer because
sometimes a rider would have to request an elevator multiple times before it was finally able enter it.
/************************
* Feedback on the lab
************************/
Concurrency is hard!
/************************
* References
************************/
JavaDocs
http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicInteger.html
Lab 3 FAQ
Recitation Slides (posted on Piazza)
Consulted with another group (loc2) on the proper behavior of ClosedDoors()