Need advice on addressing thread safety of EMF objects

[gary-johnston]

Hi. We have many Java packages and types generated from .ecore models. The generated classes directly or indirectly extend EObjectImpl. We cache instances and currently always return a copy of instances retrieved from the cache (even though we set and enforce that such instances are immutable). We'd like to avoid making these copies, but it seems like there are thread safety issues even if only getters are called on the returned instances due to lazy initialization done for some fields (e.g., EObjectImpl.eAdapters(), but there are many other examples in our own generated classes that extend it).
How is this generally handled? Does anyone have any insights into how to get around this?
Are there any levers we can pull at the EMF runtime or codegen level to make things thread safe?

[merks]

You should consider using MinimalEObjectImpl.Container as the base class. That is the current default for new models.

It implements the adapters list differently as well...

There exists no magic thread-safety bullet. Even if the list implementation is thread safe, this code cannot guarantee that x will not be added twice:

if (!list.contains(x)) {
  list.add(x);
}

Generally thread safety comes from high level management of how which threads have access to the models and how they access the models. The EMF Transaction framework has the notion of read and write transactions. Xtext and similar concepts.

We're more careful with the Ecore model to "freeze" it org.eclipse.emf.ecore.impl.EModelElementImpl.freeze() before many threads start using it. You might reflectively call eGet on all features to initialize the list fields...

[gary-johnston]

Thanks for the reply, Ed.

I think the suggestion to consider use MinimalEObjectImpl.Container as the base class was about maybe using less memory and using the current default base class (i.e., catch up with more moden EMF version usage). I agree we should consider that, but I think we should not expect it to help with our thread safety issue, correct? Not a complaint; I just want to make sure I understand correctly.

Also, I think the "freeze" support would not extend to our EMF model instances (whether they extend EObjectImpl or EObjectImpl.Container), and so would not help us get better read-only enforcement, correct? Again, just want to make sure I understand.

We thought about calling eGet on all the features. We were hesitant at first because we don't want to risk the additional memory usage (which we don't know how much it would be, admittedly). We may want to revisit this.

I took an admittedly brief look at the EMF Transaction framework, and it seems like probably overkill for what we want to do (avoiding having to make copies of object that should be read-only already) and sounds like a lot of code change to adopt it. Please correct me if I seem to misunderstand.

So I think we're probably going to have to roll up our sleeves and do some internal bookkeeping to make sure only one thread gets the instance fetched from the cache (and any other threads that fetch it get a copy). Or something like that.

[merks]

The eAdapters implementation is safer in that the contents of the array are never modified and the list is not cached. But yes, there is no magic bullet here.

I'm not sure to what extent you are enforcing read-only. Adding an adapter and throwing an exception when eNotify is called or specializing eNotificationRequired and overriding eNotify?

The list implementations for feature are generally designed to have no backing array until first populated, so they are very small. Moreover, if you are concerned about memory, you should be more concerned about EObjectImpl.

https://ed-merks.blogspot.com/2009/01/emf-ultra-slim-diet.html

Yes, high level policies around transactions/modify-operations are complex and everyone needs to follow the rules, though adapters can find rule violators. But the caching and copying doesn't sound exactly trivial either.

You've really not said much about the life cycle of these things. When do they change and how are the changes made visible to the clients?

[gary-johnston]

Re read-only enforcement, we do the former.

I'm afraid it seems like it would be a major undertaking for us to adopt EMF transactions. The caching and copying bookkeeping I'm considering would (I think) fairly localized.

As for lifecycle, there isn't much of one. Instances in the cache should never be modified. When client code requests an instance, currenly we get it from the cache, make a copy of it, mark the copy immutable and protect it, and return it (the copy), after which it's up to the client code what to do with it, how long to hold onto it, etc. We don't actively notify client code of changes.

Thanks again for your help.