Summary of Multi-Thread Collaboration and Synchronization Control
- First job · Multi-thread elevator
In the first multi-thread design, according to the teacher's suggestion, I established three threads: request simulator, scheduler and elevator operation. After the request simulator processes the input, the valid requests are put into the tray; the large loop of the scheduler first scans the tray, adds the new request to the request queue, then scans the information of the three elevators to get a snapshot, and finally loops through all the requests in the queue , perform scheduling, change the queue request status and the request queue in the elevator information class; the elevator operation only realizes the movement according to its own corresponding elevator information, and changes the elevator information at the same time. For the safety of multi-threading, the queue is only used as a private property of the scheduler to avoid multiple operations; all methods of the elevator information class are locked with synchronized.
- Second assignment · IFTTT
This job involves file operations. Considering the insecurity of File, a thread-safe SafeFile class is established. All methods are locked with synchronized, and information snapshots are obtained when objects are created. The monitoring thread follows the principle of "each trigger of each monitoring object is a thread". Each thread scans the file tree cyclically to get a snapshot, and judges whether it is triggered by comparing the old and new snapshots. ), and finally update the snapshot for the next judgment.
- The third operation · Taxi system
The threads of this job are mainly divided into three categories: taxis, schedulers, and inputs. The first is 100 taxi threads. Since it contains shared information, considering thread safety, the taxi's information snapshot method is locked to avoid multiple access. The second is the scheduler thread. Each cycle first scans all taxis to get a snapshot, then traverses the request queue, and judges in turn whether it has been completed, whether it is within the time of the order grabbing window (if yes, it will command the order grabbing), and whether the order grabbing window has ended (yes). Then, according to the taxi information received by the request, it will decide to dispatch the order), etc., and finally change the status of the taxi and the queue. The input thread is the main thread, which accepts input in a loop, checks the validity and homogeneity and joins the queue. Due to the design of the test interface, the input thread also needs to access the taxi snapshot in order to output the specified information at any time. All methods of the queue and request classes are locked to ensure thread safety.
Metric analysis
- First job · Multi-thread elevator
Number of class attributes: 46 (including all parent classes)
Number of methods: 80 (including all parent classes and interfaces)
Class total code size: 801
OO metrics:
Class Diagram:
Timing diagram:
Self review:
In terms of metrics, the same problems as last time arise - cyclomatic complexity and nested block depth, concentrated in the scheduler and elevator running classes. Because the operations in the thread run functions of the two classes are more complicated, they have a calling relationship with multiple other classes.
From the class diagram, there are many methods in thread shared resources, namely queue and elevator information, especially the latter. If you take a closer look, you will find that they are all elevator-type "set" and "get" methods. Since the elevator itself is the backbone of the entire program operation, the amount of information is large, resulting in a long list of methods.
From the perspective of design principles, the responsibilities of each class are not single. Due to lack of experience, the framework is constantly modified, which makes the logic of each class difficult to close and not stable enough (SRP). Constants are frequently used, which does not meet the principle of explicit expression.
- Second assignment · IFTTT
Number of class attributes: 27
Number of methods: 55
Class total code size: 821
OO metrics:
Class Diagram:
Timing diagram:
Self review:
From a metric point of view, the first problem is that the cyclomatic complexity and nested block depth are not qualified, focusing on monitoring threads and input processing classes. The main reason is that the monitoring thread is not classified into corresponding methods according to the trigger conditions and task types, but is directly put into the run. There are many redundant and repeated content, and the file class and record class are repeatedly called, resulting in deep nesting. . The second problem is that there are too many variables when the monitoring thread is initialized, in other words, there are too many responsibilities, which can give a glimpse of the overall code structure imbalance.
From the class diagram, with the monitoring thread as the core, the file security class as the information carrier, and the shared resource as the file tree, the relative stability of the information can be guaranteed when the snapshot is obtained through the file security class.
From the perspective of design principles, the responsibilities of each class are not single. The monitor thread needs to implement scanning, judgment triggering, mobilization and even complete tasks (recover) autonomously, which does not conform to the SRP principle; the common methods and attributes of different triggers in the monitor Lists redundancy (just to clarify ideas), does not achieve code reuse, and violates the principle of reuse.
- The third operation · Taxi system
Number of class attributes: 52
Number of methods: 44
Class total code size: 1036
OO metrics:
Class Diagram:
Timing diagram:
Self review:
From a metric point of view, except for the gui class that cannot be changed, the input processing, taxi and map classes have a large cyclomatic complexity, the nesting block depth of the scheduler and the taxi is large, and the request class has many parameters. The input processing combines the functions of the test interface, which increases the complexity of the judgment process; the map class needs to traverse 6400 points in the map.txt file and process the information in sequence, and the array is large; the taxi class handles similar processing of different states There is no merge and induction, and the bfs method is used to obtain the shortest path, which leads to an increase in the number of nesting layers; the number of lines of code in the scheduler is not much, because the method inside the request is called, and the taxi is accessed or changed through it. Considering that this method is limited to scheduler calls, there will be no simultaneous access by multiple threads, and the internal information of the request is better obtained, but it leads to serious structural defects.
From the class diagram, the map class that is not shown is responsible for reading the information of the map file and establishing the route basis for the taxi movement; the scheduler shares the taxi and request queue with the input.
From the perspective of design principles, like the previous assignments, SRP, DIP, and reusability principles are not followed.
BUG analysis
- First job · Multi-thread elevator
Public beta: all passed
Mutual testing: safe pass
Debugging: In the process of debugging, the main problem is that threads run separately, and real-time changes lead to inconsistent information acquisition. The solution is to add a snapshot of elevator information at the beginning of the scheduler cycle to ensure that the information processing period is relatively static.
Test program: The bugs assigned to this assignment are relatively serious. Except for the input processing test of the public beta, which can pass the other performance tests, there will be problems such as Exception, time error, request sequence error, and piggyback judgment error, etc., and the test is more difficult.
- Second assignment · IFTTT
Public beta: all passed
Mutual test: When the breadth and depth of the directory are 20000 respectively, there is a problem with the program running. The stress test mainly exposes the performance defects exposed by the recursive algorithm used by the program when the SafeFile class obtains the snapshot of the file tree when the amount of data is large.
Debugging: The situation of this work is quite special. All the functions were fully realized the night before ddl. Before careful debugging, I hurriedly started to write documents. On the second day, the debugging of the job was also limited, and there was no obvious error in the simple test with the test thread.
Test program: The problem of this test task is obvious. First of all, as long as it is related to the directory, there will be errors, including no response to the trigger, and the task is not completed. For the recovery task, sometimes the wrong objects that should be restored are identified, resulting in deviations in the recovery results, which may be a mistake in understanding.
- The third operation · Taxi system
Public beta: all passed
Mutual testing: The reason for the error is that some taxi movements displayed by the gui do not conform to the principle of random identical distribution. The problem should lie in the random number generated by random.
Debugging: Since the taxi state changes rapidly and the test range is limited, no serious directional errors are found.
Test program: The allocation algorithm of this test task is basically correct, but the situation that the starting point is the same as the destination is not ignored, resulting in a null pointer Exception when the taxi is driving.
experience
The three multi-threaded operations in this unit can be summed up as follows: very difficult, many details, and very mysterious to debug.
The difficulty is reflected in programming. For example, the understanding and application of concepts or grammars such as "lock", "thread safety", "sleep", and "wait-notify"; thread shared resource protection to minimize the scope of sharing; the introduction of the concept of "snapshot" to make dynamic information relatively Static; consider the multi-dimensionality of the problem, covering the state and behavior of all threads at a certain moment; follow the SOLID principle to make the program more optimized, etc.
Many details are reflected in task understanding. The tasks of the three operations are very heavy. The multi-threaded elevator needs to be selected and allocated according to the request queue and elevator status. IFTTT needs to complete four triggers and three tasks. The taxi system needs to schedule 100 taxi threads to achieve order grabbing and dispatching. I remember the first time I drew a few sketches for the process structure of a multi-threaded elevator. Every time I found a certain link infeasibility and overturned it, IFTTT finally changed it to the correct structure on Monday night. In addition to the overall framework, there are also small details that cannot be ignored but are very vague, such as judgment conditions, time, boundaries, operating standards... In order not to miss out, we can only wander in the Q&A group and issue area all day long, experiencing "Ah, I wrote it wrong again. ", "Isn't it like this", "Fortunately fortunately" roller coaster-style mood ups and downs.
Debugging should go without saying. System.out works great.
Although it was on the verge of collapse, it finally survived smoothly. grateful.