Skip to main content

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

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.






Back to the top