Jiri Klement wrote: > > I've fixed #2480 by replacing LinkedList with ConcurrentLinkedQueue > > (or at least I hope so, I don't have gps device with me to test it). > > Thanks Jiri, it is likely to be some time before I can code and test anything for JOSM. At least that will fix my immediate problem. I will test tomorrow with a GPS (I have been travelling for 2 days).
> > Just a few thoughs about threading issues... > > > > Making data structures thread safe does not necessary mean big > > synchronization overhead. For example ConcurrentLinkedQueue is about > > as fast as simple LinkedList (and a bit slower than ArrayList). I admit that I should have been more specific. I really meant "synchronized classes" rather than "thread safe classes" incur more overhead. ConcurrentLinkedQueue uses atomic actions to be thread-safe rather than synchronisation involving the scheduler. > > WayPoint class can be made immutable which would make it also thread > > safe without any performance impact. I did not understand enough about JOSM; sorry. > > > > In JOSM two threads can modify osm data - EDT and worker thread. > > That's usually ok (because when worker thread is doing some work then > > PleaseWait dialog is shown blocking EDT) but it's not perfect, we have > > some tickets about problems caused by concurrent access. It would be > > nice to have all osm data thread safe but it's a bigger change and I'm > > not sure about performace issues. That sounds OK for lots of things, but not for livegps which does not block the EDT. I have no idea whether there are other plugins which do not wish to block the gui. > > > > SwingWorker is a nice class, but we already have PleaseWaitRunnable > > that can do similar things. OK, I understand that a "please wait" blocking the EDT is fine if the user is expecting to wait to load a file (for example). However, you know that is inappropriate for livegps (which does not use PleaseWaitRunnable) and which runs until stopped by the user, perhaps for many hours. The prime thing that Swingworker adds is "publish" queueing information to the swing dispatcher thread and inserting an event into it's event queue. There a handler can issue calls to swing, or data be updated safely without contention. Obviously this could be coded independently of Swingworker. > > > > Swing should not be accessed in other than EDT thread but it's not > > true that Swing is not sychronized at all. JTextField.setText is one > > example of thread safe method. OK, I admit, I generalised. I only looked at the first swing call used in LiveGpsDialog, panel.setBackground the documentation for which doesn't mention thread safe. I suppose that the only risk if a collision occurs might be a random color shown instead of that intended. I think what you are saying is that the feedback from pseudo-permanent background threads should use swing but be limited to using those methods of swing which are thread-safe. Is that the idea? Finally, If all the developers are happy with the current state, then I will certainly not interfere and code anything which will upset you all and I certainly don't want to waste my time coding something that would not be accepted into the project. _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
