[concurrency-interest] Implicit parallelism

Aaron Grunthal aaron.grunthal at infinite-source.de
Sat Aug 10 17:18:48 EDT 2013

Thread-safety in the context of data structure usually (but not always) 
refers to consistent behavior when it is concurrently *modified*.

In your example you mention summing over a list. That's a read-only 
action and doesn't require immutable lists or special concurrency 
support. Most data structures are well-behaved under concurrent 
read-only access, barring exceptions such as access-ordered LinkedHashMaps.

Java 8's parallel streams also are smart enough to not parallelize on 
small data sets where the overhead would kill any performance advantage. 
At least for data structures that allow size-estimates or actual sizes 
to be obtained.

I think there shouldn't be anything keeping you from adding a .parallel 
if you anticipate the possibility of your data transformations handling 
non-trivial amounts of data.

- Aaron

On 10.08.2013 20:45, Gustav Åkesson wrote:
> Hi guys,
> My discussion here concerns implicit parallelism. Let's say we have the
> following setup:
> @Immutable
> public class Integer
> {
>    ...
> }
> @Immutable
> public class ImmutableArrayList
> {
>     ...
> }
> I'm looking for a way so that the parallelism would be introduced
> without hard-coding anything related to parallelism (i.e. not stating
> anything like .parallel or .par on the collection). Only thing needed
> would be something annotation-ish which tells the execution environment
> that this datastructure with elements is inherently thread-safe. Then
> the execution could determine if it would be beneficial to do so. For
> instance, for a structure with e.g. five elements, then it would not,
> but for millions of elements, it would most likely be. Perhaps it could
> even find some kind of sweet-spot of number of elements in which the
> parallel overhead exceeds the benefits.
> Let's say we wish to sum all the integers in an ImmutableArrayList
> (setup below), would it be possible for the compiler (javac, scalac or
> what have you) and JVM to conspire and decide "hey, let's run this in
> parallel since it doesn't violate application semantics and it can/will
> be faster"? Is there any research in this area in regards to the JVM?
> Best Regards,
> Gustav Åkesson
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list