Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Displaying frequently changing lists of eObjects
Displaying frequently changing lists of eObjects [message #1764976] Mon, 05 June 2017 10:03 Go to next message
Emil Ra is currently offline Emil RaFriend
Messages: 3
Registered: June 2017
Junior Member
Hello,

I have a question about the correct way of handling a constantly changing list of eObjects, which is displayed in a viewer. I've been dealing with this issue for a while now, that's why I'd like to ask for expert advice :)

In my model, some elements contain lists of other elements.
Those lists are displayed in a TreeViewer or TableViewer on the UI.
The lists' contents are changing (add/remove/modify) all the time, and with a high frequency - they are not modified via the UI.

Modifying the lists is trivial - updates are also reflected in the viewers, as provided by the EMF item providers.

The first issue I faced is that there is a memory leak when removing elements from the lists, because the item providers still hold references to the removed objects.
I read in another thread here that the correct thing to do in this case is either 1) to dispose the old item providers and create new ones (too much overhead, since there are lots of modifications), or 2) to clear the eAdapters() list of the removed eObject.

I went with 2), which reduced the number of leaks, but didn't stop them completely, and I was also seeing ConcurrentModificationExceptions relatively often.
The reason for this is that while the UI thread was iterating over the lists (updating the viewer triggered by EMF ViewerNotifications), I was modifying the list from another thread. I think that the leaks still happened, because some of the operations on the lists weren't executed due to internal safety checks in the lists.

A simple solution I did is to move the list modifications to the UI thread (Display.getDefault().syncExec()/asyncExec()).
This solved the issues, but it doesn't seem to be a correct solution - and firing off UI tasks for every list modification adds overhead.

Another option would be to add synchronization between the thread from which I'm modifying the list, and the UI thread (that would be in the EMF item provider code), but that doesn't seem to be ideal either.

Is there a better solution to solve the issues? What is the best practice for such a use-case?

Thank you very much in advance!
Re: Displaying frequently changing lists of eObjects [message #1775505 is a reply to message #1764976] Tue, 31 October 2017 06:28 Go to previous messageGo to next message
Emil Ra is currently offline Emil RaFriend
Messages: 3
Registered: June 2017
Junior Member
Hello,

Does anyone have advice regarding my questions?

Thank you!
Re: Displaying frequently changing lists of eObjects [message #1775512 is a reply to message #1775505] Tue, 31 October 2017 08:45 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33133
Registered: July 2009
Senior Member
Sorry, I didn't see your question. It's generally expected that modifications are done via the command stack so it's also expected that all objects originally in the model or at any point added to the model will leak. If you don't want adapters to cause leaks, yes you can call eAdapters().clear(). And yes, models are not generally thread safe so doing all modifications on a single thread (the same thread that's displaying the model) is one way to ensure thread safety. Dispatching an asyncExec for highly frequently occurring events can "flood" the display thread making the UI non-responsive. One way to address that problem is to keep track, in the runnable being dispatched to the UI thread, whether or not the UI thread has processed the event and to batch the processing so that when the UI does finally process the runnable it does all the work that needs to be done at that point in time. This way the display thread cannot be flooded and the background thread doesn't block for significant periods of time. A complex example of this is org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.ViewerRefresh. A simpler design in your case might be to accumulate a list of runnables.

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Displaying frequently changing lists of eObjects [message #1775513 is a reply to message #1775505] Tue, 31 October 2017 08:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I would use two helper activities to avoid arbitrary concurrency complexity. One background thread, one foreground runnable.

Any change to the list is realized by queueing a change request object to the background thread, that, if not already scheduled, is scheduled to run in 100ms. This provides a guard against thrashing for high rates of change.

When the background thread runs, it processes all list change requests to create a new list and an update request list. Once the background thread has exhausted its input queue, it schedules a foreground, UI thread runnable, to process the update request list, creating/destroying UI objects as appropriate. As much work as possible is performed by the background thread to minimize the UI thread costs.

Obviously the communication between source/background, background/foreground threads needs careful synchronization.

Regards

Ed Willink

Re: Displaying frequently changing lists of eObjects [message #1775553 is a reply to message #1775513] Wed, 01 November 2017 03:09 Go to previous message
Emil Ra is currently offline Emil RaFriend
Messages: 3
Registered: June 2017
Junior Member
Thank you very much for the helpful replies!
I'll work on this issue again in the coming 1-2 weeks, and I'll report back if there were any caveats/changes to the suggested approach.
Thank you again!
Previous Topic:Type EAttribute
Next Topic:Extend EAttributeImpl
Goto Forum:
  


Current Time: Thu Apr 18 07:26:48 GMT 2024

Powered by FUDForum. Page generated in 0.03059 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top