1. Analysis of the fifth homework
1. Design strategy
This job is a multi-threaded elevator. In my logic, the elevator follows its own operating rules. Therefore, the elevator runs continuously according to its own state, and during the running process of the elevator, the state change can be carried out according to the light. The scheduler is responsible for scheduling requests in the request queue. This is the general idea. There will be many multi-thread conflicts here: the thread safety of queues is relatively obvious, so I won't go into details. When scheduling a request, there will inevitably be a contradiction between obtaining the elevator state and changing the elevator state. Because one thread needs to read the elevator state, and one thread changes the elevator state, some code blocks in the elevator need to use synchronization. In addition, multiple elevators need to read and change the status of the floor lights, so the floor lights also need to be synchronized. After clearing this, the coding work becomes relatively easy. First, write some edge classes, such as InputHandler, Request, Floor and other classes, and then focus on the writing of Scheduler and Elevator classes, and the work in the code phase is completed. .
2. Metric information and class diagram
In this design, the biggest problem is the large dependency between classes. For example, the piggyback judgment of the elevator, etc., this method should not belong to the elevator in essence, but for the convenience of coding, the judgment of the piggyback problem is still used as a method of the elevator. Also, for get methods that return private properties, it should in fact be an immutable object, otherwise it should return a clone of the object. None of this type of stuff is given much attention in coding.
3. Bug analysis
For myself, a simultaneous bug was found here. Because true parallelism does not exist for our multithreading, even if the three elevators arrive at the same time in theory, they will not be true at the same time. There will always be a sequence, and my program will therefore assign some instructions to the elevator with less movement. Due to multi-thread scheduling, this elevator will arrive a little earlier than other theoretically simultaneous elevators, so the instructions will be assigned first.
For others, the person I assigned did not use the real-time strategy, so the elevator was not implemented with threads, so there would be a lot of time bugs, which are not typical bugs in thread scheduling, so I won’t do it here. Re-narrate.
Second, the sixth homework related analysis
1. Design strategy
This job is file monitoring. The general idea is to extract snapshots of the monitoring area at regular intervals, and then compare the snapshots of the two time periods. The method I take here is one thread for each monitoring task. The thread takes snapshots at intervals and then performs comparison operations according to its own task type, monitoring scope and other information. There is little connection between each monitoring thread, but they will share a method to extract snapshots and record summary and detail together. Therefore, the threads that record summary and detail here need to be synchronized to prevent conflicts in writing files. In addition, file operations also need to be synchronized, and the strategy I adopted is to encapsulate all file operations as static synchronization methods, use class locks for synchronization, and put the method of obtaining snapshots in it, which can greatly avoid excessive Conflicts caused by thread's file operations.
2. Metric information and class diagram
In this design, one of the better improvements is that the coupling between classes is reduced, of course, part of the reason is that various types of monitoring tasks are relatively independent. But at the same time, a problem brought about is that a lot of irrelevant information is stored in FileAttrs, which is actually a flaw from a design point of view.
3. Bug analysis
This time is the time when I have found more bugs. Later, most of the bugs were found in the monitoring folder. Since this part was added in a hurry, we did not find a small problem in judging the renaming and path changing logic when there are multiple operations at the same time, resulting in two bugs.
The code I got this time is well written, and I also use the factory pattern and singleton pattern mentioned in the class. At the beginning, I found several bugs, which were problems of understanding, and were revised after negotiation. In fact, up to now, as long as the code is relatively well written, you probably already have a basic understanding of the use of synchronization, at least you can guarantee that there will be no or fewer errors. I mostly just test others with test cases that I might have threading issues with while writing my own programs.
3. Analysis of the seventh homework
1. Design strategy
This job is taxi dispatch. To a certain extent, I borrowed the design of multi-threaded elevators this time, because they have many similarities. For example, there is an object running, there are requests, and a scheduler is needed to allocate the requests. So this time, my taxi is similar to an elevator. It has its own state and decides how to run and switch to the next state based on its own state. So, like an elevator, I synchronized the process of changing the status or attributes of the taxi itself. Unlike elevators, there are many taxis to be managed this time, so TaxiManager was introduced to manage all the taxis. And for some other problems, such as the choice of the data structure of the graph. Since the maximum degree of all points this time is 4, it must be a sparse graph. Therefore, it is decided to use an adjacency list to store edges, and use SPFA to find the shortest path of the sparse graph (equivalent to bfs in this case).
2. Metric information and class diagram
Noticed that the TaxiInfo class has too many parameters in the constructor. The solution given on the Internet is to use the Builder pattern to define an inner class Builder, whose member variables are consistent with the outer class, and define each optional variable in the outer class. A similar setter method, except that it returns itself, and the Builder's constructor returns an instance of the outer class, so that it can be constructed by chaining calls.
3. Bug analysis
My own bug is actually that some testers didn’t understand the problem. After talking for a long time, they took a step back and didn’t think they had a bug.
The person I tested only had a very simple little problem, which was that he didn't pay attention to the requirements in the instruction book. For the rest, I try to understand his output according to the logic of the code writer, and I feel that there is no problem. As for a strategy for testing, you can use a few commands to bring all the taxis together to one location, and then perform other tests.
Fourth, experience
I feel that since the fifth assignment, the design has formed a fixed pattern of its own. Relatively speaking, this process is not as headache as before. As for thread safety, it was still hazy when I wrote the fifth homework, until the first edition was written. Later, I checked the Internet carefully, and then I understood some knowledge about class locks and object locks, and therefore rewrote some of the fifth code. After tossing this time, the thread safety considerations for the sixth and seventh jobs can be smoothly reflected in the code. The process of considering thread safety mainly considers the cooperative relationship between various classes, and then starts from the Bernstein condition, and draws those classes that need to do thread synchronization measures.
For design principles, I feel that this is an issue that should be thought about in the design stage. The code that follows the design principles is relatively less difficult to write. The less difficult here does not mean that the difficulty of the homework has become less, but the workload of each part has become less, and you only need to focus on the writing of this part. Well, top-level issues such as collaboration are left to other threads to solve. That's how I feel about my work.