[josm-dev] Loading JOSM+plugins into Eclipse for the first time.

[Ray Foulkes]

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.