write in front
Multithreading
fuck people
fifth assignment
Class Diagram:
The scheduler (als_3_controller) of this job inherits the previous scheduler (smart_controller), and decomposes the previous schduel method. The content is distributed in run() and the isCarry() and run() of the new class ELE_thread. When the program is running, three threads of class ELE_thread are started, which represent the control systems of the three elevators and operate the three elevators respectively.
Metric Analysis:
The problem lies in the run() of ELE_thread, including cyclomatic complexity and nesting depth. The main reason is that most of the last code was concentrated in the run method, the code is complicated, there are many repeated parts, and the aggregation and coupling conditions are not ideal.
Timing diagram:
BUG analysis:
I am procrastinating again, and I don't spend much time on this assignment. Most of the code is changed on the basis of the previous one, and my understanding of multi-threading is not good, so this assignment is full of bugs:
1. No output to file. The first time I use java to read and write files, I am a bit rusty.
2. Schedule the same request twice. The multi-thread synchronization control is not written well, and a request enters the queue of two elevators.
3.FR is not piggybacked. Something went wrong with the piggyback judgment condition.
4. Elevator selection is wrong. The cumulative lag of the cumulative amount results in the selection of an elevator that should not have been selected.
There are still many bugs, the above is a typical selection. There are about a dozen public tests in the mutual test, but the students in the test were very nice, and after a friendly exchange, they helped me delete a few.
sixth assignment
Class Diagram:
The two main classes of this job are the monitor class and the SafeFile class. The SafeFile class encapsulates the File class into a thread-safe file class. My main approach is to add the keyword synchronize before the method. The monitor class is responsible for analyzing each request, judging whether it is triggered and notifying several task classes to execute the task. In design thinking, for each request, I start a thread to analyze it. This approach makes the writing of monitor clearer, but it is a waste of resources.
Metric analysis
Cyclomatic complexity and nesting depth are exceeded in the monitor's run method. At the time of design, almost all the functions to be implemented by the monitor are put into the run method, and there are many nesting layers. And when I was processing the monitoring file and the monitoring directory, I put them in an if-else statement, and the content of the two parts was roughly the same, resulting in code duplication. Also due to the above problem, the cohesion of the code is not good.
Timing diagram:
BUG analysis:
This job took a long time, but there are still many bugs, the reason is that the coordination of multi-threading is not fully understood (desperate face orz):
1. Some cases of rename are not triggered. When there is a deeper directory in the current directory, renanme does not trigger, because when recursively traversing the deep directory, the return value is wrong when it is not a file.
2. Some cases of path-changed are not triggered. When there is a deeper directory in the current directory, path-changed does not trigger, because when recursively traversing the deep directory, the return value is wrong when it is not a file.
3. You cannot rename after rename recover. Error in rename tracking file.
Due to the problem of black-box testing, one bug in this assignment (recursively traversing deep directories) was fixed on the branch tree, including seven bugs in the mutual beta and public beta. Coupled with several other fragmentary bugs, a lot of points were also deducted this time.
The seventh homework
Class Diagram:
The seventh job is the first job of the taxi, and several main classes that implement functions are taxi, schduel, Map and GUI. The taxi class defines a single taxi, which is responsible for various behaviors of the taxi, including stopping, waiting, loitering, picking up passengers, etc. The run method defines the transition process of a taxi in several states. After receiving the passenger request, the schedule class is responsible for analyzing the request, opening a waiting window for each passenger, selecting a suitable taxi and notifying it to pick up the passenger. The Map class is primarily responsible for initializing and storing the map with several different data structures. The GUI is responsible for the visualization. In terms of design ideas, a new thread is opened for each taxi and each passenger request, which is a waste of resources and needs to be improved.
Metric Analysis:
Only the cyclomatic complexity exceeds the standard, except for the GUI, run() in schedule and sortPath() in taxi are marked in red. The run() in the schedule implements two parts: opening a window and selecting a taxi, and the code is a bit complicated. sortPath() in taxi is a method to find the shortest path. Due to the Dijkstra algorithm, the code is relatively long.
Timing diagram:
、
BUG analysis:
It may be that the opposite classmates didn't test me very much this time, and there were no bugs and design flaws in the mutual test (although I know that I still have a lot of problems...).
When I was testing, I found that when 100 taxis stopped at the same time, sometimes there would be a few delays.
experience
After listening to the seniors say that writing multi-threading can only be called oo, I felt a chill in my heart at that time. After the baptism of these homework, I found that what the senior said really made sense. After the baptism of these homework, there are also some experiences to share with you:
1. Distinguish the instance that there are several threads to share
2. Multiple threads share an instance, all global variables in the instance are unsafe, and a synchronous method is required to change the value of the global variable.
3. One instance is used for a single thread, and all non-static global variables in the instance are safe.
4. Comprehension of synchronization block: The synchronization block synchronizes the object, which can also be said to be the memory address in the synchronization object, that is, the global variable in the synchronization object. It is unsafe to prevent multiple threads from accessing the memory address of the same object unsafely. Access global variables of the same object.
5. Note the difference between static global variables and non-static global variables
6. Don't take the chance that you can make changes on the basis of the last homework, be sure to rewrite it!
For the analysis of threads, the cooperation between threads, the understanding of synchronization control is not yet in place, more efforts in the future!
The road is long and obstructed~