Hi Andrew,
This isn't something we've had a problem with, and I think its a result
of a couple of paradigms that are entrenched in Layer behavior. First,
you might want to check out OMGraphicList. It's a wrapper around a
java.util.List that holds the OMGraphics, and all of the methods that
access that List are synchronized on it. So, you can't add stuff to it
when you are painting it, etc.
Secondly, if you modify the list, you need make sure you are generating
the list with the projection and then making sure the Layer gets
repainted. This essentially means that the latest version of the
changes to the list will be the next thing you see.
You get this for free when you call doPrepare() - a thread is launched
to call prepare() on the Layer, which for PlugInLayer will call
PlugIn.getRectangle(). If you call doPrepare() with a thread already
in prepare(), the first thread is interrupted and another one is
launched to start the process over, which culminates in repaint() being
called internally. You end up with the latest version of OMGraphicList
being displayed.
On Sep 9, 2004, at 11:22 AM, Andrew Hnatiw wrote:
>
> I hate to reply to my own post, but after looking at more source code
> I'd like to suggest that even GraphicLoader has problems with
> synchronizing on the list. My fear is that since the getRectangle()
> method of any plug-in will return A POINTER to the same list that the
> plug-in is working with, how can there be any guarantee that the list
> that was returned is not being modified by the plug-in while the
> OpenMap layer that called getRectangle is using it (even if we are
> using GraphicLoader... the GraphicLoaderPlugIn still returns a pointer
> to the list it is using internally).
There isn't a guarantee. If you need that guarantee, you should create
a new OMGraphicList in the GraphicLoader and set it on the receiver.
> If this is indeed a problem, one solution that seems simple would be
> to have getRectangle() return a clone of the object... of course, this
> would require the OMGraphicList and anything within it to be cloneable
> (did Sun ever change it to the correct spelling clonable?), so maybe
> its not a very simple solution. It is also very slow,
and can be memory intensive, depending on how many OMGraphics you are
creating.
> and I feel like I remember reading that getRectangle() should try to
> return as fast as possible.
No, that's the paint() method you are thinking of. getRectangle() is
where you should do the work, it gets called in a separate thread.
Faster is better, but that's where you can burn time to get what you
need without making the application feel slow.
> The only other solution that I can think of is for plug-ins to not
> use their 'list' member variable, and instead create a new unique list
> every time it has to return one in getRectangle() - though this could
> also be slow.
I think the only plugin that has a list variable is the
OMGraphicHandlerPlugIn. I'd use it if you want to take advantage of
the OMGraphicHandler functionality. But the PlugInLayer is also an
OMGraphicHandlerLayer.
> Any ideas? I'll have to try running a ton of threads all modifying
> the graphic list at the same time to see if I get any odd behavior...
> though chances are slim. I think that a bug like this showing up in
> the future would be hard to even trace back to this as the source.
I would find a case where things are broken, or at least not working as
you expect, before investing a huge amount of time. I don't think you
would notice the bug you are anticipating, if it did appear, unless you
are trying to guess when the PlugInLayer is done with a request to a
specific call to doPrepare() - that's way to hard to do, which is why
the Layer.renderDataForProjection method is there.
It's unusual for a ton of threads to be accessing a PlugIn, anyway. If
you have that situation, I'd put a GraphicLoader on a timer that queues
up changes on a new OMGraphicList before sending it for display.
- Don
> >
> > I was wondering how code such as OMGraphicHandlerPlugIn can avoid
> > synchronization problems. It does not seem to ever sync on
> > the graphics list, so isn't it possible that the thread creating and
> > changing the list could access it at the same time that doPrepare,
> > getRectangle, or repaint are called? OpenMap does have multiple
> > threads initially, correct (?), since it has to have things to
> > handle the GUI and redraw the screen all "at the same time"?
> >
> > I see how the GraphicLoader can help solve these problems, but am I
> > correct in thinking that graphics cannot be modified at all without
> > fear of synchronization errors when using just the
> OMGraphicHandlerPlugIn?
> >
> > Thanks,
> >
> > Andrew Hnatiw, Software Engineer
> > Andrew_Hnatiw_at_raytheon.com
> > Raytheon IIS
> > Falls Church, VA 22042
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, dietrick_at_bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Thu Sep 09 2004 - 14:25:35 EDT