OO second unit design-multi-thread elevator

First homework

According to unreliable news, I heard that the second operation of the previous elevator series directly became our first operation. . . In fact, the first time is not too difficult, mainly because I have not prepared for the arrival of multi-threading.

The homework released on Tuesday evening, I read (probably) some tutorials from Liao Xuefeng on that day , and watched a little "Illustrated Java Multithreaded Design Patterns" on Wednesday (I have to say that this is really a good book. It ’s still relatively good for a weak chicken like me friendly).

Design ideas

In the main thread main, the initialization of each object, the start of the thread, the reading of the request and the termination of the thread are left, which also leaves a hidden danger for the third job;

Encapsulate the Elevator class and use it as an elevator thread;

Encapsulate the RequestQueue class to maintain the request queue and act as a scheduler;

Encapsulate the Floor class to save the waiting queue and arrival queue for each layer.

Scheduling Algorithm

The phrase "don't make wheels repeatedly" is used in elevator design, it can be understood that: elevators have been put into use for a long time now, except for special needs, the elevator scheduling algorithm used in daily life should be close to The best algorithm. So in addition to understanding these elevator scheduling algorithms that are similar to disk scheduling, it may also be a good perspective to combine with the reality of life.

Learned some existing elevator scheduling strategies-LOOK, SCAN, etc., because I personally feel that when the elevator is idle, staying on the middle floor is similar to the performance of the up and down running to random requests. Floor (8th floor). For the piggyback rules at runtime, the ALS rules are basically followed.

In addition to these, individuals have also added a more clever (speculation) design-"delay judgment" when the elevator is going up and down-the so-called "delay judgment", that is, when the elevator is going to run from the second floor to the third floor, in After completing the upper and lower passengers on the second floor and closing the door, we can sleep (100), then we can judge whether there are passengers to go to the elevator, reopen the door if there is, and sleep (300) if not, and then reach the third floor. This can save the elevator time to go to the second floor to pick up passengers and then go upstairs (if there is only this group of passengers, and the direction of the target floor is consistent with the running direction), and in the third operation, for the next floor For the 600ms Class C elevator, the time spent on the upper and lower floors is increased by half, so "delay judgment" can bring greater rewards.

Structural analysis

 

The run () method in Elevator and the arrive () method in RequestQueue contain too many situations and perform too many operations; the main class Main is slightly bloated. . .

The functions should be divided more finely and specifically.

bug analysis

Due to the less functional requirements of this job, it is really not easy to get bugs, and no bugs were detected in the strong test and the mutual test.

summary

In addition to having more threads as soon as it comes up, the overall operation is relatively harmonious.

 

Second job

In this operation, the first operation is added to the floor (except for the 0th floor, which has basically no effect) and multiple elevators.

Structural analysis

In order to facilitate the coordination of multiple elevators, the Floor class is given more attributes and functions, and the other is basically the first operation (which shows that the scalability of the first operation is also Okk).

Here is a close-up of Floor. . .

 

 At the time of design, I wanted to arrange a dispatcher for each elevator, but I felt that each dispatcher should not only interact with the elevator, but also interact with the total dispatcher. The coupling may be stronger, so it is still based on a dispatcher. Continue to expand, which also led to the original bloated and complicated objects, methods, and now become more bloated and complicated.

 

bug analysis

This time, because of the "delay judgment", there was a 300ms less sleep for a situation, which caused two mistakes, but the overall performance was not bad.

Survived from mutual testing.

I handed over two pieces of data, and hacked a few students guiltily, and found that the most error-prone place for you may still be a deadlock-some students will shut down elevator by elevator (this will be very easy in the third assignment Loss), some students use lock or synchronized too much.

summary

It is probably more multi-threaded if there are multiple elevator projects. The debugging process is also more troublesome, especially the bug reproduction.

In this assignment, I heard that some students have already used the transfer method. I feel that this method may be targeted in the mutual test, so I have not considered it too much, but I have not encountered this in my room. Classmates.

 

Third homework

Compared with the second operation, the complexity of this operation has been greatly improved-different types of elevators, you can join the elevator halfway, and the elevator has limited floors-this has to introduce transfers.

Design ideas

Understand the methods of the students, which are mainly divided into two categories-one is a static method that designs a "route" for the request when the request is read in. This method is convenient for the later scheduler allocation, according to everyone ’s response, It seems that the performance is also good; the other is to design the "route" according to the elevator you take after entering the elevator. This method may have good dynamic adaptability, but the workload of the scheduler has to increase a lot.

I used the latter here. In fact, for the main request, the assigned elevator is also completed according to its own algorithm-combining departure floor, target floor, transfer requirements, etc.

Structural analysis

Compared with the second assignment, this assignment has a larger change:

From the main thread main, sort out the read request and the thread input that terminates the thread;

Expand the PersonRequest provided by the course group into Myrequest to meet the needs of transfer;

Three types of elevators are inherited from Elevator;

The scheduler RequestQueue adds and modifies a series of transfer judgment and execution methods.

 

 Because each type of elevator can have different floors, it is necessary to overwrite the methods inherited from Elevator (now, some methods may not be overwritten)

(The arrive () method in RequestQueue is of course the same bloated ...) 

bug analysis

I don't know why the job will be lax after the third job, so I didn't conduct more tests this time.

In fact, during the mid-test, it was found that the last point would appear CPU_TLE because of insufficient sleep time. At that time, it was probably known that this was because sleep () was used instead of wait () at the end of the judgment, but then I was lazy , I don't want to start another thread, I just changed the time of sleep (). As a result, CPU_TLE appeared at many points (even there was even a hunch). . .

 

Summary & Lesson 2 Painful Lesson

Although the third assignment is painful, its scalability should be good. For example, if you need to exit a certain elevator or several elevators, the coupling between the elevators is very small, so it should be adjusted slightly and can be directly used without affecting other threads.

Our elevator series operations cannot simply use the producer-consumer model, nor can they directly apply the worker thread model. Although it can be generally considered that the input thread provides (producer) for the request to the request queue and the scheduler, and the elevator thread (consumer) takes out the request and completes the delivery, but these traditional modes are that one thread only processes one request at a time. Our elevator needs to be piggybacked, that is, to process multiple requests at the same time (otherwise the performance must be very poor, and it is not in line with the reality of life). The elevator piggybacking strategy will inevitably increase the coupling between the elevator and the dispatcher. How to maintain the request waiting queue and the elevator carrying queue is the key to the job.

When doing the third homework in the next unit, you must force yourself to test more, and you can no longer step into the same river. . .

Guess you like

Origin www.cnblogs.com/kjs001019/p/12716007.html