1. Write in front:
After the first three homework tests, in the second stage of the three homework, because of the introduction of multi-threading, the object-oriented course has entered the "deep water period" where you need to cross the river by feeling the stones. I still remember that the fifth homework release coincided with the Qingming holiday, and the teaching assistant reminded the students to start early on the notice board. After my "practical experience", the construction process of a multi-threaded elevator is not easy. Later IFTTT, and then to the taxi dispatching system, are further applications based on multi-threading. There is no need to say much about the hardships in the process of overcoming multi-threaded design. I believe that every student has a profound experience. However, from being overwhelmed when faced with multithreading at the beginning, to the basic understanding and good application of the current stage, the three assignments at this stage have really helped a lot. Let’s talk about the application knowledge together here!
Second, the fifth assignment:
1. Multi-threaded coordination and synchronization control strategy
This operation implements a multi-elevator scheduling system consisting of 3 elevators. Referring to the instructions in the instruction book, I have designed three threads in this operation—input processing thread, scheduler thread and elevator thread. , and a tray is designed for data exchange between threads.
In the tray, I designed a total of 4 queues, corresponding to the command queue and floor request queue that the three elevators need to execute. The general idea of the inter-thread operation is that the input processing thread sends the valid input to the queue in the tray, and the request in the elevator is directly sent to the corresponding elevator queue. For the floor request that is not assigned to a specific elevator temporarily, the scheduler will continuously scan the status of the elevator, and transfer the request to a specific elevator queue after a qualified elevator appears. The scheduler will perform elevator scheduling according to the request queues of the three elevators, and then inherit the scheduling method of the last ALS, and convey specific instructions to specific elevator processes for execution.
2. Metric Analysis
(Class Diagram)
(UML timing diagram)
(Overview of Metric Graph)
(Details of the metric graph part)
Analysis: From the cyclomatic complexity and block nesting depth, my program is too complicated for elevator scheduling and input processing. When implementing these functions, it is really just to implement all the logical judgments in one method. And many processes are directly written in the run function, which is redundant. In the future, you can try to write similar functions as in-object methods, and simplify the run method to improve readability and reduce complexity.
The pallet does have slightly more data volume, and basically all data exchange goes through a large pallet. In the future, in the process of data exchange between different threads, you can consider using multiple pallets to avoid the problem that a single pallet is too complicated.
3. The bug of your own program
01.
Since this is the first time to "test the water" of a multi-threaded program, this program has some bugs at the multi-threaded scheduling level. Specifically, under certain circumstances, the operation result of the program may be correct or incorrect. This bug stems from the inexperience of thread-safe design, and did not get enough attention at the beginning of the design, which eventually led to the emergence of data conflicts and other problems, resulting in the appearance of wrong running results.
02.
One output situation is that multiple instructions are executed at the same time, and the output is the same except for the original instruction. Here I take it for granted that the same elevator can only process two commands at the same time, the floor command and the single elevator command. In fact, the floor instructions are divided into top and bottom, so there will be a situation where three instructions are processed at the same time. This situation was not considered in the design, so there is a bug in the scheduling level.
4. Bugs in other people's programs
01.
The uncertainty of thread operation, outputting different results under the same input conditions. This is similar to my first question and should stem from inexperience with thread-safe design.
02.
Correct assignment of floor requests. The problem should be that the dispatcher thread misallocated the floor request.
3. The sixth homework
1. Multi-threaded coordination and synchronization control strategy
What this job implements is a monitoring program that monitors changes in files according to instructions and responds accordingly. In addition to multi-threading, I think the focus of this work is two-fold, file processing monitoring and thread-safe design. For the latter, I specially implemented the SafeFile class to re-encapsulate the original File class, so that the class that might have conflicted becomes thread-safe, and the error caused by data conflict is eliminated from the source.
The whole program contains five kinds of threads - input processing, monitoring, summary output, detail output and the test thread used to change the state of the file. The input processing thread sends valid input to the tray and starts the corresponding monitor thread. For the monitor thread, the status of the current monitoring file will be continuously scanned and compared with the previous status. If the trigger is found to be triggered, the restore operation will be performed according to the previous status, or the information will be transmitted to summary or detail through the tray for output. . If the monitoring object is a folder, each scan is equivalent to generating a "snapshot" containing all the file information in a directory, and the operation is performed by comparing the two snapshots before and after.
2. Metric Analysis
(Class Diagram)
(UML timing diagram)
(Overview of Metric Graph)
(Details of the metric graph part)
Analysis: The design deficiency is basically similar to the last time, that is, the redundancy of the thread run method and the excessive amount of data stored in the tray.
3. The bug of your own program
Due to the tight time in the week of IFTTT design, a serious bug occurred in this program design, which made the function of monitoring the directory basically invalid. It was later confirmed that there was a problem with the sharing of old and new snapshots. I use the last and now arrays to store all the file information of the two snapshots, and perform the "last=now" operation during the next scan. This operation seems to assign the current snapshot to the array that stores the previous snapshot, but in fact, the head pointers of the two arrays point to the same location, so that now and last will not change no matter what happens, and eventually lead to directory monitoring. of failure.
4. Bugs in other people's programs
During the test, I observed that when the trigger is size-changed and the processing method is detail, the last modification time does not change when the output file changes before and after the detail file. The reason is that there is a mistake in the storage and output of the information before and after.
Fourth, the seventh homework:
1. Multi-threaded coordination and synchronization control strategy
This work implements the passenger calling and answering system of a simulated taxi.
There are three kinds of threads in the program, input processing, taxi and request. The input processing thread feeds the legitimate thread to the tray and starts the request thread with a timing of three seconds. The request thread obtains the taxi status from the scheduler (Tray), finally selects a suitable taxi, and pushes this request. The taxi moves according to the state and the valid command information received, and exchanges data with the dispatcher.
2. Metric Analysis
(Class Diagram)
(UML timing diagram)
(Overview of Metric Graph)
(Details of the metric graph part)
Analysis: It can be seen that in addition to the possible shortcomings of the gui itself, the problems of high cyclomatic complexity and block nesting depth are concentrated in the run() method, and the problems are roughly the same as before. It needs to be avoided as much as possible in the subsequent design.
3. The bug of your own program
During input processing, requests for the same origin and destination. Although the error was judged and the error output was performed, the flag was forgotten, and it was sent to the scheduler as a valid instruction, resulting in an error.
4. Bugs in other people's programs
without
Five, experience:
The three operations in this stage are a step-by-step process for Java multi-threaded applications. The main experience is as follows:
- For multithreaded programs, a good top-level design is important.
- In the implementation process, the logic must be clarified, and locks must be added where necessary to avoid data conflicts and ensure thread safety.
- Use the output debugging method when Debugging. A feasible method is to output real-time status when outputting, and monitor the change of each step, so that it is easier to find the problem.
6. Conclusion:
I still remember that Mr. Wu Ji drew the difficulty curve of homework after OO class in class. The difficulty of homework at this stage was the highest, and it reached its peak at the multi-threaded elevator. This is basically the case. The process of designing multi-threaded elevators and IFTTT is very painful, and the taxi system is not simple. However, when I see my program can run smoothly as a whole, I really have a great sense of accomplishment. In my opinion, the reason why the difficulty of homework did not increase but decreased after that was not because the homework became easier, but because we gained a lot without knowing it in the process, just like the process of breaking a cocoon into a butterfly. work to realize our transformation!
We are still on the way! come on!