The fifth assignment: multi-threaded elevator scheduling
Design Strategy
In this elevator job, I constructed one elevator request queue thread, one scheduler thread, three elevator threads, one file output thread, and the main thread.
The scheduler scans the user's request queue, and assigns each queue to an elevator that meets the requirements. Each elevator has its own request queue, and the elevator changes its state according to its own request queue.
Synchronization control mainly includes two points: the user request queue will be operated by the scheduler and the input thread of the request queue, which needs to be synchronously controlled, and the running queue inside the elevator will also be operated by the elevator itself and the scheduler, which also needs to be synchronously controlled.
For synchronization control, I used the synchronized keyword and the methods of wait() and notify() to implement thread-safe operations on shared resources.
Metric Analysis and Class Diagram
- Class Diagram:
- Metric Analysis:
In the metric analysis of the class, the complexity of the scheduler class and the elevator class is relatively high, and then the complexity of the method is analyzed.
In the scheduler, the method of judging whether it can be piggybacked is more complicated. In fact, this part can be executed by simulating the elevator button, which is mentioned in the bug analysis. The method of dispatching elevators is also more complex, mainly to judge the requests outside the elevator, analyze the cumulative motion of each elevator, etc., which can be more modular here.
The complexity of the elevator class is mainly due to too many methods, and the shortest piggyback request must be recalculated every time it stops at a certain floor. Changing the thinking can make the code a lot cleaner.
And in the run() method in my request queue, I wrote all the input judgments in the run, which is a very bad habit. The run method of the thread should be as concise as possible, and the input operation module should be change.
bug analysis
I only found a very important bug a few hours before submitting this assignment, which was caused by a flaw in my design thinking, and I didn't read the instruction book carefully. When requesting to join the request queue, if the request in the elevator should be directly assigned to the corresponding elevator, there is no need to wait for the elevator to be in a state of being able to piggyback or wait for service, but I let the request in the elevator wait. When the last modification is made, the request is directly forcibly added to the elevator queue, which leads to the piggybacking problem.
In fact, a better design idea should be to simulate a real elevator, set buttons for each floor of the elevator, change the state of the button when a request is sent, and judge whether the button is pressed when each floor is running. Ignored if it is a homogeneous request.
There is also a large error in the control of thread time, which is not particularly accurate.
Find other people's bugs
The bugs of the classmates I tested this time were mainly due to formatting problems. When outputting, many brackets were not output according to the requirements of the instruction book.
The sixth assignment: IFTTT file management system
Design Strategy
In this job, I start the input controller from the main thread, get the file monitor that needs to be opened from the input, the monitor thread starts to monitor the file in real time, the test thread is also opened at the same time, the file is modified, and the monitor detects When the file changes, the information is sent to the operation thread, and the corresponding operation is performed on the corresponding file.
In terms of synchronization control, the reading and modification of file information needs to be synchronized.
There is also a stop thread that is used to control the termination of the system. Enter the corresponding command and the system will automatically exit.
Metric Analysis and Class Diagram
- Class Diagram:
- Metric Analysis:
In InputHandler, the average operation complexity is higher, because the code written in judging the format is longer, and a more modular judgment can be considered.
The average operation complexity of each flip-flop is also relatively high. This is also related to my design idea, because I didn't notice that many triggers need to monitor the changes of all files in the directory at first, so I didn't monitor the folder at first, and after adding folder monitoring, the code became verbose.
In fact, you can use the nested loop single file monitoring method to achieve folder monitoring, which will be more concise to write.
Bug Analysis & Self Analysis
- bug
When testing a deeper directory, my output will be very unstable. For example, if the previous recorddetail.txt is not deleted, it will easily become unstable, and the problem of thread safety has not been solved.
- self-analysis
I put all the classes in the default package, this architecture is not very good. Both the monitor class and the operation class can be placed in separate packages, and the monitor class can also be written to inherit a parent class, and they all have the function of monitoring files. My program is still lacking in scalability and maintainability.
The better part of the program is that it uses an Operation class to select the operation, and only needs to call the Operation each time, instead of calling the method of each operation separately.
Find other people's bugs
The other party is lacking in thread-safe design. After many files are modified, the monitor can detect them, but no corresponding operations are performed, resulting in many outputs being empty.
The seventh assignment: taxi dispatching system
Design Strategy
For each taxi, I open a thread, and for each request that meets the requirements, I will open a scheduler thread to schedule the taxis, add the taxis that meet the requirements to the queue of the scheduler thread, and schedule After the server thread runs for 3s, it selects the most suitable taxi from the queue and sends the request to the taxi for execution. During the execution of the request, the taxi needs to be locked to prevent other scheduler threads from scheduling the taxi.
Metric analysis and class diagram:
Class Diagram:
This time, different functional modules are placed in different packages. Information is used to store data, taxi is used to store taxis and taxi queues, locaiton is used to store coordinates and maps, scheduler is used to schedule, and passenger is used to store request queues , enter the request.
Metric Analysis:
Except for gui, the taxi class has the highest average complexity. Taxi movement and state transition do require many functions to determine the implementation, so the inevitable increase in complexity.
Bug Analysis & Self Analysis
- When the starting point and the ending point are the same, I did not make a mistake in judgment, but let the taxi take the order. There is also no real-time output for the output of the taxi information file.
The old problem, the time interval of the output has errors. It is found that the sleep method of the system will indeed produce errors, so I wrote a sleep method to accurately control the sleep time.
- Originally, I wanted to use the observer pattern for this assignment, but since there are not many observer classes involved, after I used observer and notifier, the code became very complicated, so I finally gave up using this method. I feel that the design pattern is still More research is needed.
Find other people's bugs
The problem was found at the time of thread scheduling, and the input of two identical requests at the same time was regarded as two time requests, which may be the delay in the intermediate code.
After the taxi roamed freely, through the console output, it was found that some did not stop for a second at the allotted time.
There is also no output from the process of finding the shortest path.
experience
1. More research is needed on code structure and design patterns. From the beginning, all the classes are written together, and then the functions of different classes are classified into different categories, and some progress has also been made. The use of interfaces and abstract classes requires more practice to enhance the maintainability and extensibility of the program.
2. In terms of thread control, there will always be some problems in the accuracy of time, mainly due to some delays in thread scheduling. No suitable solutions have been found for these problems. What we can do now is to try our best to Simplify the amount of code to run.
3. I feel that I start writing code without systematic study every time I do homework, resulting in many links in the middle that cannot be written and have to go back to learn, and there is no overall framework. Just need to consolidate the basic knowledge.