Assignment 5: Multithreaded elevator
The design conceived at the beginning is to enter one thread, one thread for each of the 3 elevators, and one thread for the scheduler. The input thread deals exclusively with input requests and adds legitimate requests to the request queue. This time, since it is the real time of the simulation, the homogeneous request can be judged directly when it is input. The scheduler is constantly scanning the request queue, and for each unallocated request, see if there is an elevator available. The elevator thread is an automaton, it just moves according to the set state. Then there is the question of how the program ends. The input control thread can obviously end when the input end flag is entered, the scheduler can end after the input ends and the requests are all allocated, and the elevator ends when the scheduler ends and no requests are assigned to it. After that. There is nothing wrong with the general pattern of the design. Later encountered some detailed problems, mainly the uncertainty of multi-thread scheduling, and the accumulation of time errors. After there are many requests, it is found that the time error of the operation has accumulated greatly and can affect the output, so a time is pre-stored in the elevator. Every time you want to sleep for 3s or 6s, use the stored time to calculate what to sleep. At some point in time, update the saved time and erase some operational errors, and the effect is much better.
From the class diagram, since the request class has various attributes and corresponding methods, it looks very huge. Considering the problem of division of labor, this class can be refined. From the metric point of view, the run method in the Ctr_new class has high cyclomatic complexity. This class mainly inherits the scheduler of the last elevator, and basically retains the design of the last elevator. The number of parameters of the print method in the Main class is high. This is mainly to consider the output of multiple threads. A function is specially written for the console output and placed in the Main class, and synchronized is added. Because the output of each thread requires different parameters , they are directly merged together, in fact, there are many that are not used, you can consider dividing them into several methods. The run method block of the Elev class has a high nesting depth. Consider subdividing the responsibilities of this function while avoiding duplication.
This time, the multi-threaded elevator is quite satisfactory, and no bugs have been picked up in the public beta and mutual testing. When testing other people, they construct small data by themselves. Specifically, it is to test whether some functions are fully implemented. Since there are many kinds of answers on multiple threads, it is not easy to check the correctness if the data is large. When the code of the opposite person was tested for a certain big data, he found a problem. He tried to find the source of the problem, and after narrowing the data, he found that it was correct again. He couldn't find any reason by looking at the code, so he was not wrong.
Assignment 6: IFFFT
The design idea of this assignment is very simple, and the focus is on various operations on the File class. The main thread is that a request input corresponds to a monitor thread. After processing the input directly in the Main function, according to the number of legal input requests, each monitor is opened in turn, and the monitoring saves the information of all files within the monitoring range at a certain frequency according to the monitoring mode, and compares the difference between the two adjacent information. point, according to the monitoring mode to decide whether to respond accordingly. This time about thread termination is to customize a method to let the tester terminate all threads, because after all, monitoring a file itself has no termination condition.
From the class diagram, the SafeFile class is relatively large, mainly for the thread-safe packaging of the File class, which is understandable. Monitor class has too many properties. From the perspective of Metics, the cyclomatic complexity and block nesting depth of the run method of the Monitor class are high. This run method is almost the core part of the entire program. All the judgment, scanning, and response work of the monitor are placed here. It is very process-oriented, and there are quite a lot of repeated code segments. I myself think this segment is ugly. You can consider a more detailed division of labor, cutting out several methods or creating several new classes to share some responsibilities.
Regarding your own bugs, there is no problem with your own program itself, it is the layout of the test thread. Since the input is not specially written in a thread, it may block the test thread, so the test thread can only be opened before the input, which is considered a bug. . For other people's code, I did some simple functional tests, and the other side just made a small mistake in an illegal situation, and I also found the reason. Nowadays, for multi-threaded testing, due to the contingency of multi-threading in the execution process, I will find specific bugs and then report the specific reasons from the code. Feel like I've learned something and avoid making similar mistakes.
Homework 7: Taxi Scheduling 1
The design idea this time is very similar to the multi-threaded elevator, and because of the gui, many things can be used with it. First, enter a thread of the controller, process the input of the request, and add the legitimate request to the request queue. The scheduler scans the request queue, selects suitable taxis for requests within each window period to initiate grab orders, and selects suitable taxis for dispatching orders for requests at the end of the window period. One of 100 taxis is a thread, and each taxi acts in order according to the current state. The main interaction is that the taxi itself is an automaton and will change its state. The scheduler selects the taxi to dispatch and changes its state from the outside world. The method of multi-thread elevator is used in the time error, and the error is reduced to almost negligible. The bfs in the gui has been improved, and the shortest path calculation is placed in the program initialization, preprocessing to obtain, and less operation time during the running process.
After learning the SOLID principle this time, basically each class is divided into very detailed divisions, and there is no god class and idle class. From the class diagram, the Taxi and Req classes are a bit large but acceptable. From the Metric measurement, there is no problem with my own code. The red part is the gui code, which has nothing to do with me.
This time I made a serious mistake, that is, when processing the input, I created a new local variable. After that, all the input is written overwriting. When creating a new request, I directly pass the local variable into it. Because java These variables in are actually pointers, which caused the request to be continuously overwritten and caused 3 bugs by the tester. When testing by myself, the small data is input after a long interval, and the big data is directly added by writing another piece of code, but it is not found, and it is a big loss. When I tested the opposite side, because there were few public tests, it was just some illegal situations. I first read the code for the opposite side, and found a function implementation that was inconsistent with the instruction book. Then I tried a random big data stress test and found that the results were very poor. Far. The design principle is not carefully studied
, (I originally wanted to add an explicit expression principle, but it’s okay to be too soft-hearted.。
experience
- Thread safety is mainly when multiple threads access the same data, read and write, and when multiple threads perform IO operations. Pay attention to using synchronized locking to limit, but don't add too much, which will affect the efficiency.
- In terms of design principles, my main consideration is the balanced distribution of responsibilities. Make the responsibilities of each class clear, so that the code looks clear and easy to maintain. Explicit expression, understand the principle is also accustomed to, variable name naming rules to follow, I have a mind. The principle of reuse is also what I have been paying attention to, which can reduce the redundancy of the code. Other principles will gradually become accustomed to in the future study.