Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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,
Antonio

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
  2. 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.

 

Thoughts?

 

Thanks,

Sina

_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epsilon-dev


--
Antonio Garcia-Dominguez

Back to the top