After these three OO homework experiments, I mainly learned the realization of java multithreading.
The first is the multi-threaded elevator series. Since I mentioned in the last summary work that I will change my own implementation, this time I will benefit from the implementation of the elevator I changed.
Let me talk about the way the elevator was designed in the past: because there is only one elevator, I did not separate the work of the dispatcher and the elevator. Therefore, one of my schedule classes is particularly bloated, about 400 lines, which also includes the pattern of using a lot of judgment caused by the unclear thinking of my own design.
The design of the improved elevator: First, the functions of the scheduler and the elevator are separated. The scheduler is only responsible for adding requests to the elevator's request queue according to the elevator's running status. The elevator is only responsible for its own operation, and every arrival Check your own queue for piggybacking problems on the first floor.
Because there are three elevators in the fourth operation, it is obvious that the first design method is difficult to achieve.
After separation, the idea of multi-threaded elevator is relatively clear, just follow the design pattern recommended by the guide book step by step.
First, build a pallet class. This pallet is actually a queue of requests to be maintained. The user keeps adding elevator requests into the queue, and the scheduler continuously scans the request queue and the elevator queue, and adds requests to the elevator queue that meets the conditions.
Then, the operation mode of the elevator has not changed in general. It may be that there is a lot less judgment (homogeneous) in the running queue of the elevator.
In a single-threaded elevator, the judgment of my homogeneous request is judged by the queue of the elevator, but this time I moved the judgment of homogeneous request to the scheduling of the total pallet scheduler, by introducing a light class to judge homogeneity (which works in a similar way to real life). When the request enters the tray, it can be judged whether it is a homogeneous request.
Then the most important problem comes, that is, the conflict of multi-threading.
1. With my light system, there will be conflicts when switching the lights on and off.
2. For my pallet queue, the request to join the pallet and the request to dispatch to the queue of each elevator, this part will conflict
3. After the elevator does not reach the first floor, it will scan its own queue to see if there are piggyback requests, but its own request queue may be dispatching new requests
4. When the scheduler dispatches a request to the elevator, the elevator is also running and will change at any time.
This is the main problem to be solved in this homework yao
1. The conflict resolution of lights is relatively simple, mainly by adding the synchronized method where the lights are turned on and off, the synchronization problem of the lights can be realized.
2. The implementation of the growth and reduction of the tray request queue is also relatively simple, as long as you add synchronized to the method of requesting the queue and the method of dispatching by the scheduler.
3. The elevator scans its own queue idle, and the solution of adding a request to the request queue by the scheduler is similar to 2
4. For elevator dispatch and elevator operation, I didn't consider this problem when I wrote it, because I didn't quite figure out how to lock an object, and the object was still running (I only learned about the synchronized method at the time).
Then I thought that when requesting to scan the elevator status, the status of the elevator should not change, so I created a permission class to communicate information between the elevator and the scheduler. When the scheduler scans the elevator status, it will get the elevator At this time, the elevator cannot change its state. After the elevator scans all elevator states and completes one scan of the pallet queue, release the elevator's use rights and let the elevator change its state.
For the elevator, as long as you want to change the state, such as adding one floor to the floor, when the state changes, you will get your own permission, and after the state change is completed, your permission will be released.
Although this implementation looks complicated, because I didn't know the lock method at the time, now I just need to add a lock to each elevator, instead of creating a static permission class to solve the problem between scanning elevator status and elevator operation. between the problems.
In the test, the bug was not detected in my own program, but the opposite bug was detected, mainly because of the piggybacking problem. The ER operation was input to the same elevator at the same time, but the sequence was 87654321, and it would not send the last request. incidentally. In addition to this, some piggybacked requests are not handled properly.
Below is the class diagram of my assignment:
This time the class diagram is more complicated, because the elevator's scheduler, scheduler, and input part all have to operate on the request queue, and I also introduced the system of lights, and the scanner also has to operate multiple classes, which leads to the structure Very complex and confusing.
It can be seen that the method of scanning the queue class is very complicated. It seems that I have read the code because all the information of the elevator is saved, and the judgment conditions used are also very complicated. I think the judgment method can actually be divided into two methods. , it may be that your judgment method is too complicated.
In general, this homework is relatively difficult, because it is the first time to contact multi-threading, and there are a lot of things to learn. The work took about four days in total. It will be better in the future, everything is difficult at the beginning, then difficult in the middle, and difficult at the end.
The file system is the most painful assignment I've ever written, and I feel like it's useless.
This time, because of the previous multi-threading experience, the thread conflict is relatively easy to solve. After all, the scanner will scan the request queue at regular intervals, and the conflict is relatively small.
The main problem of this job is the realization of functions, including the realization of the entire architecture. I'll focus on my heart-wrenching journey of doing this work in the next session.
The first is the question of the monitor, what is the condition of a monitor, is it a condition, a file, or an IF statement, and finally, under the final consideration, an IF statement establishes a monitoring thread.
The second problem is the realization problem. My idea is to introduce the factory pattern and treat the factory as a single piece. What I want is to use four types of triggers as the originals in the factory, and the behaviors executed after the four triggers as the original price in another factory, and then in the In a general task factory, the trigger and the executor are assembled as a task output, but when it was implemented later, it was found that the interface of the executor was difficult to unify, so I had to put the executor in each trigger, so my There are a total of four .java files for the trigger.
But on Tuesday afternoon, I found that I forgot to add the monitoring directory, so I almost rewrote the code of the four triggers. Here I also realized the drawbacks of the factory pattern, that is, if one place needs to be modified, then The amount of work to modify is very large, although the use of the factory pattern will make the architecture of this program very simple. Since I temporarily added the behavior of checking the directory, I have not cared about the quality of the code, so I added a lot of if statements, so each of my triggers is very bloated, and it would be quite simple to use the factory pattern.
When approaching ddl, I found that my program could not respond properly to deleting files. Finally, I found that it was my own design problem. I ignored it. Renamed and path-changed did not exist before, but this requirement exists now, which leads to I was still revising this part an hour before the end of the homework, but I finished it in the first half an hour.
In the end, two bugs were detected in this homework, which is fortunate, because when I thought that many bugs would be detected, these bugs can only be regarded as my own understanding problems.
One is my monitoring object problem. I limited the input to ten statements, because I thought the monitoring object was an IF one. But in fact, each file or directory is an object. Another is the problem of recover triggering record twice, because when the file is moved to another folder, its monitoring scope will also change, and I have not changed, so there will be a problem of triggering twice.
When testing the bug of the other party, the other party's detection directory function was not implemented, and the function of the detection file was not wrong, and a lot of points were deducted.
Here is the class diagram for this assignment:
Judging from the structure of this time, the structure is still quite clear, but because this time the job is temporarily driven out, the structure of each class is actually quite complicated. The monitoring of a single file and directory is basically carried out through if Judging, the similarity of monitoring files and directories is not reflected in the code, so the cyclomatic complexity of each class is particularly high (can't catch up with ddl, especially on Tuesday almost restarted writing).
From this homework, I understand that it is best to start preparing for OO in advance, and don’t wait until Monday night to start reading the questions. This kind of delay makes my homework very painful to complete. I started thinking about it on Monday night, and then started writing. Part of the data processing and structure, I started to rewrite the electrician's internship report at 4 o'clock in the afternoon on Tuesday, slept for three hours, started to debug while attending class, wrote documentation, and continued to debug and improve the program in the afternoon, 10 minutes before the deadline handed in. That week was really miserable. In the future, I must start writing on weekends so that it will not affect my other subjects.
The seventh operation is the first operation of the first taxi. Compared with the previous two operations, this operation is relatively simple. The understanding is also deeper.
The job implementation method this time is similar to the multi-threaded elevator. The only difference is that the dispatch of the request is divided into two steps. One is that the car will scan the request queue by itself, and then issue an application for order grabbing. Seconds later, the request selects the most suitable taxi among the taxis that issued the order grab request according to the judgment conditions, and then assigns it to it. The process of judging conditions is similar to the first time, and the corresponding taxi must be locked. Status, this place I add a lock to each taxi.
The conflict analysis this time is similar to the conflict analysis of elevator requests. Here I also found a problem that has always existed for multithreading, and this problem is also difficult to solve, which is the following situation: (there is no good solution)
The three processes of queue entry, queue dequeue and taxi's scanning of the request queue are mutually exclusive, which can be solved by locking, but the scanning of the queue by 100 taxis is not mutually exclusive. If the scanning is also synchronized, the scanning of the queue by 100 taxis will also become sequential. When there are many requests, the efficiency of the program will be very low, so I have been asking how to implement the scanning of the queue by 100 taxis. Exclusive, but the dequeue and enqueue of the queue are mutually exclusive?
In the test of this assignment, although there is a gui, it is still not easy to debug, and a bug was detected. The design has not been tested, so I can only analyze it myself.
In the test for the opposite side, the function of the opposite side is perfect. After the format is tested, it is found that the request for the same starting point and ending point is not judged by his program, and the rest of the aspects are very good.
This is the class diagram for this assignment:
The class diagram this time is very simple, because it is the first homework. However, some classes I wrote have some problems, probably because of the complex structure, but they are all problems with high complexity in processing input. Some can be handled by constructing another method, but there is still a problem with the input that has a very simple structure in my opinion. It is the input of the map. I think it may be too many judgments, but in my opinion these judgments are It is essential, one is to judge whether the file exists, the number of lines in the file needs to be judged, and the legality of each letter needs to be judged, so the cyclomatic complexity is relatively high.
In general, through these several assignments, my ability has improved a bit, but it is far from enough. The code specification, coupling degree, and design principles are rarely considered. I hope that I can work hard in the next assignments. use these principles to regulate their behavior.