Re: [epsilon-dev] Concurrent EOL collections?

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Sina,

Thanks for sharing your proposal. I agree that the first approach is
cleaner. Are there any known performance implications of moving to the
concurrent classes? In terms of breaking existing code, I'd be mostly
concerned about use of Epsilon from within Java - e.g. using an
EolModule to collect a sequence of elements/values from a model and
then blindly casting the result to a List in Java. I'm not too worried
about Set/Map as the new classes also implement the Set/Map
interfaces, but ConcurrentLinkedQueue doesn't seem to be implementing
List. Incidentally, I wrote a test that depends on concrete types just
a couple of days ago [1], which doesn't sound like a good idea in
retrospect, but could be indicative of how Epsilon may be used in the
wild. What does everyone else think?

Cheers,
Dimitris

[1] https://git.eclipse.org/c/epsilon/org.eclipse.epsilon.git/tree/tests/org.eclipse.epsilon.eol.engine.test.unit/src/org/eclipse/epsilon/eol/models/ModelGroupTests.java?id=c4b9fcfaa06ed61a4d3801e154fe488af1bd8ecc#n129


On Sat, 18 Apr 2020 at 13:34, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:
>
> Hi everyone,
>
>
>
> Now that we have parallel execution infrastructure in place for Epsilon languages, I was thinking whether it would make sense to add thread-safe collections to avoid errors when using parallel implementations. For example, the user may have in the pre block of an EVL script a Map or Set, and writes to this from the constraints. This would lead to ConcurrentModificationException unless the user declared a native thread-safe type. To shield the user from requiring to do this and having knowledge of what thread-safe types are in Java, I propose two options:
>
>
>
> Make existing collections thread-safe where possible. Specifically:
>
> Bag -> java.util.concurrent.ConcurrentLinkedQueue
> Map -> java.util.concurrent.ConcurrentHashMap
> Set -> java.util.concurrent.ConcurrentHashMap.KeySetView
>
> Add concurrent types:
>
> ConcurrentBag -> java.util.concurrent.ConcurrentLinkedQueue
> ConcurrentMap -> java.util.concurrent.ConcurrentHashMap
> ConcurrentSet -> java.util.concurrent.ConcurrentHashMap.KeySetView
>
>
>
> I personally think option 1 is preferable since it retains backwards compatibility and avoids the need for the user to explicitly declare concurrency or be aware of the option. As far as I can tell, there wouldn’t be any breakages from changing these types, provided users do not rely on their Java implementations e.g. if someone did obj.getClass().equals(“java.util.HashMap”), which would be a silly thing to do in EOL anyway.
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Sina
>
> _______________________________________________
> epsilon-dev mailing list
> epsilon-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epsilon-dev



--
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos

EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm