[epsilon-dev] Concurrent EOL collections?

[Sina Madani <sinadoom@xxxxxxxxxxxxxx>]

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