We are providing you a tool that performs dynamic checks to detect incorrect synchronization. The idea behind these checks are described in the paper Eraser: A Dynamic Data Race Detector for Multithreaded Programs. The Eraser central protocol/principle is that if a field is accessed by multiple threads, then there should be some lock that is always held whenever the field is accessed.
The Eraser protocol is only approximately correct. There are violations of the Eraser protocol that are correctly synchronized, and synchronization errors that don't violate the Eraser protocol.
java -cp ~jfoster/checkSync.jar:. edu.umd.cs.pugh.CheckSync Simulation
Possibly broken synchronization on Elevator.myFloorThis states that the variable Elevator.myFloor could have been accessed by different threads not holding a common lock. In this case, it points out that the last time the variable Elevator.myFloor was accessed, in method Elevator.currentFloor, a lock named Elevator was held. The current access, which occurred in the method Elevator.serviceFloor (with a stack trace showing how this was executed), had no locks held. To use this tool well, you will probably want to give your threads meaningful names. You can do this by using the constructor Thread(String name); in the case you are extending Thread, just include super(myname) as the first line of your constructor.
Previously accessed in Elevator.currentFloor in thread Elevator 0
with the following locks held: Elevator
current access in thread Elevator 0:
Elevator.serviceFloor(Elevator.java:108)
Elevator.lessDumbAlgorithm(Elevator.java:172)
Elevator.run(Elevator.java:236)
with no locks held