I. Overview
This unit uses multiple threads to implement elevator scheduling. Compared with the previous unit, it focuses more on the thread-safe mode. Compared with the previous unit, the difficulty is improved. Overall, the learning results of the first unit are not good. The first and second operations in the three operations are smoother. The third operation is invalid due to thread safety problems. More headaches. In the three scheduling tasks, I chose the ALS scheduling strategy in the guide book. I did n’t think about more efficient strategies myself, nor did I analyze various scheduling strategies like the big guys in the seminar. Make a visual chart, choose the best among the best, and choose the best scheduling strategy. This is what I didn't try hard to do. The work in this unit has many shortcomings.
2. Design strategy analysis
These three operations use the producer-consumer model, with the input as the producer and the elevator as the consumer, and they are connected by a dispatcher. The scheduler maintains a queue to store requests. Each time a new request is added, the request is added to the scheduler queue. The dispatcher then distributes the request to each elevator for execution. There is also a request queue inside the elevator. According to the ALS principle, each time the main request is used to control the operation of the elevator, the request in the request queue gradually becomes the request in the elevator. When the request input, the dispatcher request queue, and the elevator internal request queue When stopped, the program ends. Some methods of the scheduler are decorated with synchronized to solve the problem of synchronization and mutual exclusion of the waiting queue.
First operation: single elevator
The first time the whole is relatively simple, only one producer is needed at the time of design, a request queue is used as a scheduler, and an elevator consumer is fine. According to the method mentioned above: the elevator's operating strategy is that if there is a request in the elevator, the request in the elevator will be processed first; otherwise, the earliest request outside the elevator will be received and executed. The floor remains unchanged.
Second operation: multiple elevators
The second operation increased the number of elevators and the number of people allowed in the elevator. I did n’t think of more optimization algorithms, so I chose to use the modulo method to divide the request equally to each elevator thread through the scheduler. There was no change in the scheduling strategy. The main iteration of the program was to increase the number of people in the elevator thread. Judging and deciding whether the newcomer can get on the elevator, the scheduler changes from a simple Arraylist to each element in the Arraylist is still an Arraylist, and the total request queue is subdivided into different dedicated request queues for different elevator threads.
The third operation: multiple elevators
My third job is an invalid job, but there should be some problems with thread safety. I think it should be possible to talk about design strategy design methods. Because different types of elevators are involved, passengers may need to transfer to reach the destination floor. I have defined 1, 5, and 15 as three transfer floors. The request processing is similar to the second time, and the request is divided into three request queues of A, B, and C, and then divided into different types of elevator threads through the refined request queue. The principle of request allocation: determine whether the request can be completed without transfer, and give priority to the elevator that does not transfer. If the request needs to be transferred, allocate it to the elevator where Fromfloor exists on the floor where the elevator stops. The priority assigned to each request is in the order of ABC (because the working range of A-type elevators is greater than B-type and greater than C-type. However, the influence of the passenger capacity of ABC-type elevators and the effect of the number of different types of elevators on the overall efficiency are not considered. There is still a lot of room for optimization and improvement). Each elevator still adopts the ALS strategy. Unlike the second operation, some judgments must be added on the floor where the elevator can stop.
Third, the scalability of the third job architecture design
The entire elevator design idea has always been the producer-consumer model. The expansion of elevator types can be achieved by adding attributes and judgment conditions to the elevator category. The expansion of the elevator function only needs to be similar to the operation of the first unit. Add the corresponding method to the elevator class. For the comprehensive dispatching of many kinds of elevators, most of them only need to change the dispatching method in the dispatcher to complete the expansion and improvement. Generally speaking, with appropriate design patterns, it is obvious that the expansion and iteration of the program has been more strengthened.
4. Program analysis based on metrics
The third job is always an invalid job, so in the design of the program, I have always been looking for bugs at the end. There is no more optimization and improvement of the simplicity of the program to reduce the degree of coupling. In the end, no bugs were found.
The third homework collaboration diagram:
5. BUG in your own program
The first job: The first job did not fully understand the meaning of multithreading. When the order of processing requests did not follow the input, the processing of the request was started, but the processing of the elevator was started after the input of all requests was completed. The performance of the program is extremely poor, and there is a point timeout in the strong test.
Second assignment: After understanding more about multithreading, the wrong way of handling requests in the first assignment was changed, and there were no bugs.
The third job: the last issue should be the thread safety problem, making the third job invalid, and finally the timeout, or the understanding of thread safety is not in place, and found that synchronized can not blindly modify the method, because the method will be locked when the method is modified Living all this variables in the method, it should be more clear that this variable needs to be protected in the operation, and understand what to do in each step. And you must have a good understanding of the working methods of threads. If you can't just notifyall () with one method, you will wake up the newly sleeping thread without brain, causing timeout and more trouble. In short, you need to have a relatively complete cognitive understanding of the interaction between threads and thread safety to write the right program ... It is really a big loss to learn art.
6. Experience
1. A good measurement must be made between the performance and correctness of the program.
2. Choose a good design mode is conducive to subsequent iterative development
3. The original oo job was not rushed to complete after the method was devised. Not much debugging time was left every time. As a result, the thread safety bug appeared in the third job and it was not resolved in the end. The job turned over ... Write hard as soon as possible
4. Learn to master automated testing ... Improve the ability to debug, and be as rigorous as possible during program design, and dig less for yourself (will not be hurt by automated testing.
5. In the future, oo learning should be harder and harder to learn by yourself ... Read more and learn more, otherwise it will be a real supply station ... Invalid homework is really terrible