The fifth assignment: multi-threaded elevator
Synchronization and control of multiple threads
- In this operation, the request generator keeps adding elevator requests to the request queue, the master scheduler keeps distributing the elevator requests to the slave schedulers, and the slave scheduler keeps reading the requests to control the elevator operation. A synchronization relationship exists.
- The main request queue is shared between the request generator and the main scheduler, so it is necessary to synchronize the adding, deleting and reading methods of the main request queue. The method I take for this is to add synchronized code to the calling code of the caller Piece.
- The elevator and the slave request queue are shared between the master scheduler and the slave scheduler. In the method of acquiring the elevator, I use the synchronized method to synchronize the method, and the same method as 2 is used for the synchronization of the request queue.
OO metrics
Class Diagram
The class diagram shows the reference and sharing relationship between various classes. The disadvantage is that the class diagram is too complicated and the reference relationship is confusing.
sequence diagram
design angle
This assignment feels like a serious violation of the principle of revealing expression. It is reflected in the number that each constant is directly used, and there is no static variable of the class. If the demand changes in the future, such as the floor height changes, the number of elevators changes, all the codes need to be modified. Applying the Single Responsibility Principle a little better, the master scheduler is responsible for dispatching requests, and the slave scheduler is responsible for taking requests from its own slave queue to control the elevator operation. The relationship between the master scheduler and the request generator is the relationship between the consumer and the producer, and the slave scheduler and the master scheduler form the relationship between the consumer and the producer.
bug analysis
One test point in the public beta was down, and one in the mutual test was down. It's all caused by the same reason: after getting the request, the piggybackable and homogeneous ones are removed first, and then the remaining requests are distributed. The problem with this is that if elevator 1 is going to the 20th floor, and the new incoming request is scanned for the 19th floor, my program will first assign the request to go to the 19th floor to elevator 1, and then look at the allocation that cannot be piggybacked. Homogeneous request. If the next request is for elevator 2 to go to the 20th floor and the movement of elevator 2 is small, the previous request to go to the 19th floor should be allocated to elevator 2.
During mutual testing, I found a lot of each other's bugs, but I didn't report them based on the principle of harmonious 6 series. . The problem of the other party is that the code logic is too complicated, and there are many loopholes that have not been considered. Just entering a few more requests will cause bugs.
Sixth assignment: IFTTT file monitor
Synchronization and control of multiple threads
The main competition for this job is the writing of summary and detail files. The write methods I have taken to both summary and detail are locked, so that mutually exclusive access to different threads can be achieved.
OO metrics
Class Diagram
I think the idea of writing this assignment is still very clear. Different monitoring threads are started by reading monitoring commands. Each monitoring thread continuously scans the folder to see if any files have been modified, and if so, records the information through the Summary and Detail classes.
sequence diagram
design angle
This design follows the principle of reuse, and writes the common data of the four monitors, such as snapshots, summary and detail recorders, into the parent class Monitor. The four monitors inherit the parent class Monitor, and then rewrite them according to their own needs. Detection code. However, the Single Responsibility Principle is not followed well. For example, InputHandler should only generate requests, but it generates monitor threads. This part of the principle should be borne by the main thread.
bug analysis
No bugs were found in the public beta and mutual testing of this homework. The test code I got was of poor style, alternating references between various classes, which obviously caused the situation of reading and writing at the same time. Due to the poor readability of the code, I directly conduct black-box testing based on the readme. According to the bug tree to construct different test cases, I think the most likely problem is to combine the recovery task with renamed and path-changed monitoring, which is prone to timing problems. Sure enough, the other party hung up two points here.
The seventh assignment: taxi system
Synchronization and control of multiple threads
The competition for this job appears in
- Scheduler dispatch <--> request simulator to join the request
The scheduler accesses the taxi state <--> the taxi changes its own state.
For 1, I used the LinkedBlockedList blocking queue to avoid the competition problem. For 2, I chose to lock the methods of accessing the taxi state and changing the taxi state. Methods.OO metrics
Class Diagram
sequence diagram
design angle
The course of this assignment talks about SOLID design principles, and also talks about 12 other design principles that should be paid attention to in engineering. Design principles will also be considered during the testing process. Therefore, writing this homework pays more attention to your code style than the previous two.
The Single Resposibility Principle and the principle of balanced responsibility distribution : the map is responsible for providing the route, the taxi is responsible for moving forward according to the route, the scheduler is responsible for reading the taxi information allocation request, and the InputHandler is responsible for reading the input.
Hierarchical abstraction principle : Abstract the whole problem into taxi class, passenger class, passenger queue class, map class, and scheduler class.
Display expression principle : All constants are replaced with static variables of the class. Minimize the use of arrays to directly access information, such as taxi information, an array can be used to save its location, status, id, credit, although convenient, but the array subscripts are easy to be confused. Therefore, a CarInfo class is used to store information, and each time the taxi information is accessed, the taxi returns a CarInfo class according to its current state.bug analysis
No bugs were found in this public beta test, but one bug was found in the mutual test: the time for taxis to grab an order and the time to go to the passenger's destination were incorrect. The reason for this problem is that there is always a certain error between the system time and the fake time of the taxi system. I use the real time of the system for the time I output the order grabbing time, and the fake time of the taxi system is used for the time to go to the passenger's destination. Therefore, in theory, the difference between the two times is too large. Change the taxi rush time to the request issuance time + 3s.
When testing the other party's code, I found that there is actually in the other party's code. . The contents of the instruction book did not appear at all. And according to its code, it should be a follow-up job of this job. . Obviously, the other party either has the super ability to foresee the future, or copied the code of the past. . Originally, there is nothing to say about this situation, the code style is also very bad, and there are multiple unrelated classes in one file. . The class names are also illogical, and it's really annoying to read. I ended up bombing with massive requests and found that the other side's taxi thread would stop running in some cases. Another bug is. . No requirements analysis document was submitted. .experience
These three jobs are not easy to complete, especially the multi-threaded taxi IFTTT. The former is the first multi-threading job, and the latter's instruction book is too imaginative. I think that before starting to write homework, you must analyze more, simulate various possible situations, and determine the framework and data structure to be used before writing the code. Otherwise, it is very likely that half of the writing will find that the design is seriously flawed and have to be rewritten. Discussion with classmates is also extremely important. On the one hand, some things stipulated in the instruction book are complicated, some are simple, and you can check whether you understand each other properly; It is also clearer and clearer, which will definitely help a lot in completing the homework.