After a preliminary understanding of object-oriented programming thoughts in the first unit, Ben Kogan started the second unit-multi-threaded learning. The operation of this unit is to construct a qualified "destination elevator" model, design the scheduling algorithm by itself, perform reasonable scheduling, and fulfill the needs of all passengers. Since elevator requests and operations are real-time operations, a multi-threaded design is required.
First homework
1. Construction stage
The demand for this operation is to design a single elevator that can be piggybacked. The elevator floor is 1 ~ 15 floors. The piggyback strategy can be designed by itself, and the elevator capacity is not limited. After comprehensively comparing a variety of elevator scheduling algorithms, I adopted the following scheduling strategy: when there is no one in the elevator, the LOOK algorithm is used; when there is someone in the elevator, the ALS piggyback strategy given in the guide is used for piggybacking, this scheduling Generally speaking, the algorithm is easier to implement, and the performance is also guaranteed.
For the construction of the class, I mainly constructed two thread classes: Inputter and Elevator , and constructed the Controller class Controller , which is responsible for the scheduling of personnel. Inputter and Elevator use the classic producer-consumer model, share Controller objects, and use synchronization methods when accessing the Controller . In addition, because the LOOK algorithm is used many times, I constructed the tool class LOOK for calculation. Regarding the problem of thread stop, the Inputter has a clear stop condition in the input interface, and informs the controller when the Inputter stops. For the elevator thread, when there is no one in the elevator, the main request is obtained from the controller. There are three cases:
1. If the request queue is not empty, directly add the first request to the elevator
2. The request queue is empty, but the input device is not stopped, then wait
3. The request queue is empty, and the input device has stopped, then the obtained request returns null, indicating that the elevator thread is stopped.
The class diagram is shown below:
Complexity analysis:
Most of the methods with higher complexity are analyzed by algorithms, the remaining methods have lower complexity, and the coupling degree of key algorithms is still higher.
2. Evaluation stage
Strong test phase:
Since the elevator piggyback algorithm was not scientifically designed at the beginning, many requests that could be piggybacked were refused to piggyback, resulting in the final individual data points being directly judged wrong because of the long scheduling time, and the performance score of the correct data points is also very low.
Mutual test stage:
Because the overall structure of the elevator is relatively simple this time, it is not easy to have bugs in the operation logic, so I did not find any bugs during the mutual testing phase. I used the automatic data generation program to submit several test data, but no hack to others.
3. Reflection and summary
This assignment is the lowest score among the three assignments. Although the first homework is the most basic, but I didn't understand the knowledge of multithreading in the first week, I spent a lot of time in the program writing phase to pass the test, and did not optimize too much This leads to poor program performance. Therefore, when you learn new content in the future, you must understand it from the beginning, so that you can save a lot of effort.
Second job
1. Construction stage
In this operation, on the basis of the first operation, multiple elevator settings were added, and the number of elevators was determined from the beginning. At the same time, the setting of the number of passengers in the elevator has been increased, and the operating floor has also been expanded to the basement (-1 ~ -3 floors). On the whole, there are not many contents that need to be expanded for this job, so on the basis of the first job, I changed from one elevator thread to multiple elevator threads. In order to reduce the amount of expansion and increase iterability, I strictly separated elevator queue requests from different elevators at the beginning. When a request was received, the request was added to a certain elevator's request queue through an algorithm, which could not be changed. When designing the distribution algorithm, I integrated the principle of average number of elevators, and at the same time, it was not easy to be affected by extreme data. The principle of random number distribution was adopted. At the same time, the current queue and the number of people in the elevator were considered, and the frequency of the random number generation interval was adjusted (such as the current A elevator If the number of people waiting and the number of people in the elevator are large, the frequency allocated to elevator A will be reduced accordingly. This allocation method is easily achieved by adjusting the random number generation algorithm.
The scheduling algorithm of a single elevator is basically the same as the first operation, and the piggyback strategy only needs to add the number of people. Another point to note in this operation is that the number of elevators needs to be determined based on the input of the first line of the input thread, and the input thread is a separate thread. Therefore, in order to reduce the interaction between threads and ensure thread safety, the elevator thread The establishment is completed by the importer thread. The main thread only implements the establishment of the controller and the importer thread. The initialization of the controller (waiting for the establishment of the queue) is also completed in the importer thread.
The class diagram is shown in the figure:
Complexity analysis:
The complexity is similar to the previous assignment, mainly because the similarity between the two assignments is high.
2. Evaluation stage
Strong test phase:
Since this job uses a relatively good allocation algorithm, the performance score is greatly improved compared to the previous job. However, due to a major flaw in the construction-a problem occurred in the elevator capacity judgment, which led me to force the test to directly hang 3 points, the score is still low.
Mutual test stage:
As mentioned above, because of the bugs in the code itself, I was hacked twice. Fortunately, it was a homogenous bug, which was merged and fixed once. In addition, I submitted multiple data through the automatic test data generation program, hacking to two bugs of the roommate.
3. Reflection and summary
The biggest problem of this operation is that the local test is not in place, the data strength is not enough, and it depends too much on the mid-test results, so no major bugs have been found. In future tests, I will try my best to consider the test data that may cause errors, construct more targeted test samples, and increase the possibility of finding bugs.
Third homework
1. Construction stage
In this operation, on the basis of the previous operation, the setting of elevator type is increased. Different types of elevators have different passenger capacity and different floors. At the same time, the operation also added the setting of the dynamic change of the number of elevators. Initially, there are three elevators, and new elevators can be activated halfway. The input interface also has certain changes. The requests are divided into carrying requests and adding elevator requests.
Elevator classification, a very common problem caused by different callable floors is that some requests cannot be satisfied by one elevator operation (some floors cannot be parked) and need to be transferred. Therefore, it is no longer appropriate to continue to use the PersonRequest class in the output interface as the basic request class. In this assignment, I constructed a custom MyRequest class. Since there is no situation where a transfer cannot be reached, the MyRequest class contains two PersonRequest objects, which represent two requests before and after the transfer (both are atomic requests and can be reached at once). If there is no transfer, the latter is set to null. The key method of MyRequest , convert, represents transfer. The request after transfer is assigned to the request before transfer, and it is set to null, so that it can meet the needs of transfer. In addition, I used the factory mode when generating the Myrequest , calculated the transfer route after inputting an original request from the input device, and avoided generating too many calculations in the elevator thread.
The difficulty of handling thread safety problems in this operation has been greatly improved, mainly because in addition to the input device will generate a request, the elevator itself will also generate a request (that is, the elevator is both a consumer and a producer), the complexity of thread interaction The improvement is greater. In addition, thread safety and stop correctly is also a difficulty in this job. Because the elevator itself will generate requests, if the design of the last operation is adopted, the stop of the input device and the empty of the elevator are used as the elevator stop conditions, which may cause some passengers to fail to reach the destination. Each elevator thread was completely independent in the last job. The stop of one elevator does not affect other elevators, and the elevator threads in this job have interaction. Therefore, for this operation, I used "input stops and all elevators are idle" as the conditions for elevators to stop at the same time.
Elevator idle means that the elevator is empty and there are no new requests. Because the elevator is idle and the input device is stopped (the input device stops in a permanent state, it will not be turned on again after stopping, and the elevator is dynamically changed), so I used the "observer mode", the controller acts as a Role, the elevator updates its own status every time a request is processed, and informs the listener, who then updates the elevator status. Since a certain elevator can only obtain the status of other elevators from the controller, the method of acquiring the status and updating the status must be a synchronous method.
The class diagram is as shown (because there are many methods for this job, the internal methods are not shown in the class diagram):
Complexity analysis (too many methods, only some methods with higher complexity are posted):
2. Evaluation stage
Strong test phase:
In this assignment, I learned the lessons of the previous two assignments and conducted many evaluations. There were no bugs in the strong test, but the overall performance score was low.
Mutual test stage:
I survived this mutual testing phase. Of course, I did n’t find other people ’s bugs or even download other people ’s code .
3. Reflection and summary
The main problem of this operation is that the performance of the strong test is too low , and the performance of many test points is 0 . The comparison between the previous two assignments is mainly because I did not spend enough time in designing the transfer algorithm , or that the related algorithm does not . I use a "random number transfer algorithm" similar to the scheduling algorithm, but this job is obviously inappropriate. First, because each elevator runs at a different speed, try to use the elevator that runs faster. Second, because the random number is generated Some of the transfer floors may run in vain (for example, from 3 to 9, resulting in a random number of 15, resulting in a transfer path of 3 → 15 → 9, which is obviously unreasonable), of course, there may be other reasons. The assignment design of this job is actually related to the knowledge of data structure, so I will consolidate the knowledge of data structure in the future, learn more about algorithm knowledge, and do better in details.
Malleable thinking
Elevator is a very widely used tool in life. It may be extended due to various needs, which can be realized when the code is extended. Analysis of the elevator designed by this unit can reveal certain irrationality. For example, elevators only aim to fulfill all passenger requests, and do not consider the order of satisfying the needs. In reality, if an elevator often allows a first-come passenger to wait too long, then it will not be approved by the user. Therefore, it may be possible to proceed from the performance when expanding, and take the passenger's waiting time as a part of the performance score, and the waiting time of each passenger has a non-linear relationship with the performance reduction (passenger patience often increases with the waiting time A sharp decline). At the same time, setting priorities for different passengers, passengers with different priorities waiting for the same time have different impacts on performance.
The elevator of this unit adopts a simple limitation of the number of passengers, and the reality is that the elevator's passenger capacity is related to the passenger's weight, and the passenger's weight is given at the time of input. In addition, in reality, passengers cannot know their weight before entering the elevator. Therefore, more reasonable scheduling must be performed to reduce the waste of time caused by weight problems to open and close doors and affect performance.
Unit summary
Multi-threaded design is a problem often encountered in programming. In the study of this unit, I learned the way of JAVA to realize multi-threading and the principle of thread scheduling, and learned the classic "producer-consumer model", "Observer model" and other frameworks have further improved my programming capabilities. Thread safety is an important issue that needs to be dealt with in multi-threaded design. I still have a lack of processing in this area. I will continue to consolidate relevant knowledge to the extent that I am proficient in multi-threaded design.