| Re: [epsilon-dev] Concurrent EOL collections? |
Hi Dimitris, Thank you for your thoughts. I agree it’s not straightforward and, as mentioned, the motives are a bit contrived. I personally have found myself using ConcurrentHashMap in Epsilon programs, but no other types. Certainly the concurrent types cannot replace existing sequential ones due to incompatibility with null elements. I think the alternative of having separate concurrent types makes a lot more sense, would be simpler to manage and not break compatibility with existing types. For completeness, if we decide to include these types, we should also modify the grammar and editor to highlight these as “green” (i.e. built-in primitive types):
I’ll do some experimentation and see if it is as straightforward to implement in practice as it is in theory. If this seems reasonable and the implementation is a “success” (all tests passing), should we include it in 2.0 or wait until after? Thanks, Sina From: Dimitris Kolovos Hi Sina, Thank you for investigating and sharing your findings! From the discussion so far I get the feeling that replacing the default implementations of collections won't be entirely straightforward and may require more discussion and exploration of alternatives. I'd be reluctant to make such a fundamental change so close to the release of 2.0 so my suggestion would be to create a new branch and explore this further. If we wanted to sneak support for thread-safe collections into 2.0, I'd be more comfortable with the ConcurrentBag/Set/Map solution, which is purely additive and hence is guaranteed to be backwards compatible. Thanks, Dimitris On Tue, 21 Apr 2020 at 01:35, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote: > > Hi again, > > > > I experimented with the idea of making EOL collections thread-safe during parallel execution, but abandoned it, for three main reasons: > > > > It complicates maintenance. There were quite a few places I had to make change in order to support this: mainly the createInstance method which is called from a couple of places in the DOM. > The choices are limited. Although I have a custom CLQ, I would also need to make a custom ConcurrentHashMap to support null keys. Seems like a lot of effort. > Using synchronized collections badly hurts performance in parallel execution. If the user has declared something in the pre, then it’s likely to be read-only anyway. If so, then parallel execution will suffer, since only one thread can read at a time. Even using the Collections.synchronized wrappers, still makes no guarantees regarding manual iteration using the iterator, so can’t guarantee thread-safety anyway. > > > > So basically it’s a pointless endeavour: can’t guarantee thread-safety, worse performance in all cases and more maintenance. > > > > Thanks, > > Sina > > > > From: Sina Madani > Sent: 20 April 2020 18:55 > To: Epislon Project developer discussions > Subject: RE: RE: 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. > > > > Thanks, > > Sina > > > > [1] https://stackoverflow.com/questions/6692008/java-concurrenthashmap-is-better-than-hashmap-performance-wise > > > > 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, > > 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: > > > > 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 > > > > > -- > > Antonio Garcia-Dominguez > > > > > > > > _______________________________________________ > 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 _______________________________________________ epsilon-dev mailing list epsilon-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epsilon-dev |