Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epsilon-dev] Concurrent EOL collections?

On reflection, ConcurrentLinkedQueue is a bad idea: it doesn’t permit nulls and the size() implementation is broken. I have an improved version in org.eclipse.epsilon.common.util.SizeCachingConcurrentQueue which works around these issues, but I’m sure there will be some corner case that I’ve missed in the implementation. Perhaps Antonio’s suggestion of substituting thread-safe types when using an IEolContextParallel is more sensible.


From: Sina Madani
Sent: 20 April 2020 12:23
To: Epislon Project developer discussions
Subject: RE: Re: [epsilon-dev] Concurrent EOL collections?


Hi Antonio and Dimitris,


Thank you for your thoughts and raising those concerns.

Regarding the performance hit, as far as I’m aware ConcurrentHashMap only synchronizes on writes and its algorithm is extremely efficient, comparable to HashMap [1]. ConcurrentLinkedQueue doesn’t synchronize at all, so performance would be like LinkedList. Is Bag commonly used in Epsilon? I was under the impression that most would use Sequence.


I agree that ConcurrentLinkedQueue is no replacement for List: that is not the intention. Since Bag permits any collection, I thought it would make sense to have Bag be something different since we have that freedom API-wise. It is often a programming error to cast Collection to List: List is an extremely overused interface. I think if the user is relying on Bag’s underlying implementation being a List, then their program should rightfully fail if this is changed: List is not part of the EolBag API. It is only co-incidental that the underlying Collection is an ArrayList.

Going forward, for consistency I think it would be better design to convert all EOL collection types to implement interfaces rather than extent existing classes, since the latter restricts what we can do whilst the former is generally recognised as better design, according to traditional OO principles anyway.


Note that I didn’t mention anything about Sequence or OrderedSet: if someone really needs these kinds of collections and wants to write to them concurrently and doesn’t want the performance hit of synchronization, then they’re asking for the impossible and are on their own. For more reasonable use cases, a ConcurrentLinkedQueue provides deterministic ordering and is lock-free, hence the suggestion of Bag.







From: Antonio Garcia-Dominguez
Sent: 20 April 2020 08:53
To: Epislon Project developer discussions
Subject: Re: [epsilon-dev] Concurrent EOL collections?


Hi Sina,


Wouldn't there be some type of performance hit if we change that globally?


I wonder if we should just make it so concurrent implementations use those thread-safe collections, and non-concurrent ones use the same old ones.


Kind regards,



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:


  1. Make existing collections thread-safe where possible. Specifically:
    1. Bag -> java.util.concurrent.ConcurrentLinkedQueue
    2. Map -> java.util.concurrent.ConcurrentHashMap
    3. Set -> java.util.concurrent.ConcurrentHashMap.KeySetView
  1. Add concurrent types:
    1. ConcurrentBag -> java.util.concurrent.ConcurrentLinkedQueue
    2. ConcurrentMap -> java.util.concurrent.ConcurrentHashMap
    3. 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.






epsilon-dev mailing list
To unsubscribe from this list, visit



Antonio Garcia-Dominguez



Back to the top