OO second blog summary

(1) From the aspect of multi-thread coordination and step control, analyze and summarize three operations to design strategies and their changes.

Multithreaded elevator:

Since it was the first time I came into contact with multithreading, I hurriedly started it without understanding the concept, which caused thread synchronization to be very confusing. Now let’s analyze it again, and find that the idea is actually quite clear. There is a producer-consumer relationship between InputHandler and scheduler, and there should be a thread-safe requestTray in the middle. There is also a producer-consumer relationship between the scheduler and the storage queues of each elevator.

IFTTT:

In this assignment, I think my multi-thread control is much better than the elevator, and there are no bugs caused by threads. The important reason is that the multi-threaded collaboration of this job actually only occurs in file operations. To put it bluntly, it is the conflict between the creation of snapshots and the modification of files by the test thread. Then you only need to lock when the snapshot is created, and lock all the methods of the test thread at the same time.

taxi:

I think my thread safety is complicated this time. The InputHandler needs to read the status of the elevator, the elevator itself needs to read and modify its own status, and the request monitor also needs to continuously read the status of the elevator. In this way, the consumption caused by the switching of locks is very high, and it is also prone to bugs.

 

(2) Analyze your own program structure based on metrics

Multithreaded elevator

 

It can be seen that some of the main methods of this operation, such as the run of the main function, the update of the elevator, the function for judging homogeneous requests, and the function for piggyback allocation, the cyclomatic complexity of these very important functions is still very high. Very bloated. Part of the reason is because this is the third job of the elevator series, so I have been adding things to the original functions, but at this time, I have not been able to use inheritance and polymorphism flexibly, with high cohesion and low coupling. Thoughts are not well implemented.

 

IFTTT

 

 It can be seen that the complexity of this job is much better than the previous job, and it is also scattered a lot. The reason is that the overall design of this job is relatively clear, and each trigger has a specific method to judge. But the disadvantage is that I put all the logic for judging trigger conditions in the SafeFile class, which leads to a very, very high complexity of this class. I can't think of a good solution for this either.

It can also be seen from the class diagram that my design idea this time is relatively clear, unlike the elevator that keeps adding things up, which is very messy. The thread of each trigger is instantiated in the main function Run, and each trigger outputs information through the trigger function. SafeFile encapsulates quite a few file detection methods.

first taxi

 

The class diagram looks messy due to the addition of GUI this time. In addition to the GUI method, the methods with high complexity are still concentrated in the run method of the main thread, such as Taxi and Scheduler. What surprised me is that the class complexity of InputHandler is so high. After checking the code, I found that there is a checkStatus function in it that uses a continuous if-else and loop structure to check the status of 100 taxis as a test interface. This also shows that multiple if-else logic structures and switch-case structures should be minimized in future designs to reduce complexity.

 

(3) Analyze the bug of your own program

Fifth assignment:

This assignment is the first time I have been exposed to multithreading. I rashly finished writing the program without fully understanding the multithreading mechanism. In the end, I found that thread blocking, deadlock and many unexplained thread conflicts would occur, resulting in most of them being effective. I haven't passed the point, but I still met a kind person who saw that I had a thread safety problem. . A few points were given. .

Sixth homework:

Since it has not been tested, I don't know if there are any bugs

The seventh assignment:

The biggest problem with this job is the synchronization time. Because the running time of my program is too slow, although I use extra time to output, there will still be some bugs during the running process, and these bugs will recur randomly. A total of two were found, one was the car with the highest credit when the order was received, and the other was the wrong output time.

 (4) Analyze your own strategies for discovering other people's program bugs

 The fifth assignment did not find the bug. The sixth job found a file security bug, and the seventh job found a bug caused by two taxis not being synchronized.

The usage strategy usually depends on the readability of the code under test. . If the naming is really hard to understand, I usually use black box testing by classification tree and brute force testing. If the naming is better, I will analyze it according to the program. For example, the movement amount of the multi-threaded elevator + piggybacking and other boundary points, the boundary points when the taxi stops when getting on and off, etc.

(5) Experience

Multithreaded elevator:

First of all, it may be that my program has no bugs in the third homework, which led me to mistakenly think that my ability is not bad. As a result, the multi-threaded elevator waited until Sunday to take out the instruction book and start reading. For multi-threading, I also underestimated its power, thinking that it is just a tool similar to regular expressions, so in terms of multi-threading, I rashly started programming without fully understanding its principles, and I did not do it well. Complete design. The end result is that I stayed up all night to write the code, but the bugs were a mess, and I didn’t know what went wrong with the multi-threaded interaction. The debug task was arduous, and I couldn’t realize the elevator well.

Lessons learned: Understand the principle of multi-threading and then write the code by hand. You can write some small-scale programs to verify your conjectures. Otherwise, it is difficult to debug such a huge amount of code as an elevator. Design must come before implementation, preferably on manuscript paper. Write the pseudo-code of the logic and draw the relationship diagram of the interaction between classes; finally, don't delay, start writing early and allow enough time.

IFTTT:

I think this homework and core lies in the creation of "snapshot". The essence of this job trigger is to compare the difference of the file information under two monitoring, so only the "snapshot" of the file information needs to be stored. The thread safety problem (access violation) is also between the snapshot read and the test thread modification. As long as this relationship is clearly analyzed, the establishment of thread safety is very easy. This time I initially realized the importance of design.

First taxi:

This time I deeply felt the disadvantage of weak data structures and algorithms. . The bfs written by others ran out in an instant. . The bfs I wrote will seriously affect the operation of the program, and even bring inevitable bugs. In the next assignment, I must optimize the algorithm and reduce related bugs.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325154865&siteId=291194637