Safe way to operate on List while using Threads

[Kam_1]

Hi, I have a problem, because I have a list, in which I'd like to be able to add and remove components, but in other thread I use components from this list. Is there a safe way to operate over this list? Would using synchronized functions (one for drawing, one for modifying help?

[JamesCherrill]

You could synchronise drawing and modifying, but that would prevent them running concurrently and immediately halve the performance of the app and make the UI less responsive (not to mention the complexity and overhead of all that synch).

So if you just want to loop thru the list while drawing, despite the model updates happening concurrently...

either use a copy of the List to loop thru the contents:
for (car c : new ArrayList<Car>(cars)) {...

or use a CopyOnWriteArrayList

or use a ListIterator

... but maybe your problem is more complex - eg you are changing the roads and intersections... you can make each list safe individually, but it's harder to ensure that the two lists are consistent across threads. You need to provide more details if this may be the case.

ps: When you ask a question here it's normal to provide some feedback on the answers you get, so others looking for simlilar problems know whether the answer was useful. It's also good manners .

[Kam_1]

Well, you got me :D
I indeed have problems with roads and intersections, because in my app (traffic simulator) I can choose how the road system will look like - I have roads and array list with lanes in it and linked list with cars in every lane. Problem is that since I added intersections I must have done something to make the cars go where I want them to, so the solution was to remove car from lane linked list, add it to linked list in intersection and after that remove it from intersection linked list and add to correct list in lane in road on which the intersection is. The problem is that in the same time cars are being painted by draw function in other thread every 100 ms, so there is good chance the car that is drawn will be erased in the same time. For now I'm going to try with other class that will paint cars and will have second linkedlist, to which I will add only new cars, erase only cars outside of graphics window and do it I hope more secure. I hope it will work. Thanks for response.

[JamesCherrill]

Not sure why, but something seems uncomfortable about moving Cars around like that. I guess the code gets quite tangled?
How about just keeping a list of Cars, and having current location (instance of Lane or Intersection) as an instance member of Car?
My guess is that it would work well both for updating the model (updating the Car's current location) and displaying the Cars in their current position, with very little to worry about in terms of concurrency.
J.

[Kam_1]

Not sure why, but something seems uncomfortable about moving Cars around like that. I guess the code gets quite tangled?
How about just keeping a list of Cars, and having current location...

Yea it indeed would have few advantages, but I see a major problem: I would have to check cars position and compare it to all intersections, all other cars, and all roads, in my solution I have cars in lane (LinkedList) and I just compare it with car ahead (collision check) and intersections on this lane, and there is still problem with deleting cars, because I would have to remove car from collection if it was outside the window, so I would have been left with Concurrent Modifiction Exception.

I just thought about the idea that should be even better - where intersections are not on roads but between them, so rod would start and end on intersection or side of panel, so I would have to check only last car in Lane LinkedList to know if it is still on road (is not near intersection) and add car only as addFirst to the list. I think it would work even smoother, bot I have no idea how to store roads.

Well, I could only say, if I had to write something like traffic simulatro second time, I would choose C++, because with pointers and references to objects it would be much easier.

[JamesCherrill]

Time for a confession: this application is close to my heart because, in years gone by, I worked for IBM as a programmer and spent 2 years on on a project to optimise traffic light timings. It had a detailed traffic flow model that synched with real life via inductive sensors on the road, and was used to model the effects of different traffic light timings in real time to select the best timings. IBM even filed a patent in my name for some of the optimisiation techniques. I realise that your app is going to be simpler, but at the same time I know where it could be going...

However... a couple of observations:

I would have to remove car from collection if it was outside the window

road would start and end on intersection or side of panel

Almost certainly a confusion about design. Nothing in your model should refer to the UI in any way. Ditch MVC and you are guaranteed a heap of spaghetti. Alternatively: if you are creating data structures to optimise the UI painting then you are suffering from premature optimisation. How do you even know that there will be a paint performance issue?
Get the model right first, add one or more UI's later.

I would choose C++, because with pointers and references to objects it would be much easier.

I don't have any axe to grind about the relative merits of different languages, but what do you think Java object variables and arrays/collections are? Your statement implies some fundamental misunderstanding about them. Maybe you can give an example of how you would structure this code in real life with C++ pointers that isn't the same as Java references?

In best OO style: the way to resolve some of your model design questions is to forget computers and think about real-life.
Roads have Lanes. Lanes are connected by Intersections. At intersections cars may have to wait for (1) traffic signals, or (2) a gap in a cross-flow before moving into the next Lane. When they wait they may form a Queue. Cars are either moving alog a Lane or sitting in a Queue... you get the idea. Get your thinking straight about that and the model will write itself. When the model is working the UI is just a slog through MVC and the details of your chosen UI library.