Remember once debug

In the HIT software structure lab6 in, he asked us to simulate decision-making process with multiple threads monkeys across the river.

Tectonic thinking of this experiment is actually relatively simple, is to create a thread for each decision monkeys, each monkey only has its own decision-making, but all the monkeys share a river. This means that there is a race condition.

It may be the case, while two monkeys decision to select the same position, the result will bump into each other, ranging from overlapping positions, while the program crashes.

To avoid this, we need careful planning to ensure thread-safe as possible while also improve efficiency.

Learn multithreaded programming is the main safety purpose of the experiment.

Experiment only required to achieve GUI, there is no requirement for animations, but because I am more busy, just wanted to give it a try, so I decided to try to cross the river course animated monkey.

Preliminary achieve animation effects

My idea is to use JComponent to draw a monkey across the river.

Requirements on the guide books say, all of the monkeys are 1s to make decisions as a unit, that is to say, all the monkeys will be updated once every 1s state, even if the monkeys did not move.

If you want to achieve full animation, which is the process of moving each of the monkeys were to show up, then, if there are 30 monkeys, it means 1s to be redrawn 30 times, the number of monkeys more than one, is bound to affect the normal decision calculus of judgment, will make the movement of the monkey simulation is not accurate, so this is not desirable.

So I think per second, drive all the monkeys before the decision, calling once redraw the timer, so you can minimize the resource consumption.

The basic idea is this programming.

Maintaining a data structure on a ladder position monkey Map <Integer, Integer> of List, key map is the coordinate value of the ladder in the monkey, value is the monkey id. Different element represents the list of the ladder

Starts per second, with a list of the read class VisualMonkey, then converted into a coordinate value, and then to the Component, to draw on Component.

This was originally designed to be easily extended after some after this experiment pay up even though I certainly would not want to come back to look at the code for one.

The basic idea is very simple.

Written after the program tries to run it

. . . . . . Huh? Why do overlap.

There have been very serious problem, the same monkeys also appear in a number of positions on the ladder, it must be what went wrong

Investigation bug

componnet problem?

I saw this bug first reaction is --component redraw failed, only to draw a new pattern, is not struck the old pattern.

Behind this speculation proved justified, but I was wrong vowed to some out here, really wasted a lot of time.

I search the Internet a lot of knowledge about the components of java redraw, including repaint, validate, revalidate, update have tried, from the component to the Panel contained outside, traverse called once all relevant redraw method can not solve this problem.

Then I tried to be empty on the inside Component g of paintComponent method, and then re-draw, failed

Then I try to re-create the Component Object, everything from scratch, but still failed,

According to the normal logic, component part should be no problem, bug out in other places, but because Lab3 kind and has a great swing grievances, so anyway I want to overthrow it, so spent an hour, the code has been magic to change I do not understand, I finally decided to explore other roads.

Forgotten update

I began to wonder, perhaps component redraw be faithfully executed, and there is a possibility that the old monkey position is not deleted.

Since the time of ADT monkey testing, they perfectly complete the mission, so I still think there will not be a problem.

Wait, I seem to have forgotten what

？？？

ADT is not wrong, component is not wrong, then the problem is ......?

......

Ah, that was it.

Breakpoints found VisualMonkey class, and found that indeed the species from the List to convert the coordinate values went wrong, I only map was put, but did not clear the previous

This is not caused by thread-safe, but the complexity of multi-threaded indeed makes it easier to ignore these issues.

Seems to be required before each conversion, the map empty