Provide thread-safe and concurrent sequenced collections with insertion order?

[Stuart Marks]

Hi Sebastian,

Regarding the lack of "synchronized" wrappers for Sequenced Collections: the main 
issue is that they provide only a limited sense of "thread safety" and as such don't 
add much actual value. Specifically, the synchronized wrappers hold a lock only 
around invocations of individual methods. This omits a large class of common, 
compound operations on collections, such as check-then-act operations and bulk 
operations that involve iteration or streaming. These operations aren't thread-safe 
with synchronized wrappers. To perform these operations safely from multiple 
threads, the client needs to do its own locking around the compound operation. This 
mostly defeats the purpose of the synchronized wrappers.

If you need to use something like LinkedHashMap/LinkedHashSet from multiple threads, 
my recommendation is to write your own class that exposes exactly the set of 
operations you need and that does proper locking for those operations. It can then 
delegate the appropriate operations to an internal collection.

Regarding concurrent collections: these are mainly intended for operations to 
proceed concurrently on different parts of the collection, such as updating 
different mappings in a ConcurrentHashMap simultaneously, or having 
producers/consumers operating on different ends of a Queue. I note that 
historically, the concurrent collections haven't included concurrent versions of 
LinkedHashSet/Map or general-purpose List implementations. (There is 
CopyOnWriteArrayList/Set, but they're highly specialized and can be prohibitively 
expensive for use cases that involve a lot of updates.)

While it looks like things are missing from the concurrent collections, I'd have to 
ask what use cases would be satisfied by adding something like a "concurrent 
sequenced set" (or map) that wouldn't be fulfilled with a customized wrapper around 
LinkedHashSet/Map.

s'marks


On 11/2/23 4:56 AM, Sebastian Fischer wrote:
> Hello.
>
> I am new to this list so might have missed previous discussion about this but 
> could not find what I was looking for in the archives.
>
> The Sequenced collections JEP adds the following static methods to 
> java.util.Collections.
>
> - unmodifiableSequencedCollection
> - unmodifiableSequencedSet
> - unmodifiableSequencedMap
>
> However, the set of static methods returning thread-safe versions of their 
> arguments (like synchronizedCollection, synchronizedSet, and synchronizedMap) has 
> not been extended.
>
> As a consequence, I don't see a straightforward way to create thread-safe 
> sequenced sets or maps where encounter-order corresponds to insertion order (like 
> LinkedHashSet or LinkedHashMap) and access them as SequencedSet or SequencedMap.
>
> When using the available methods mentioned above, the result is not a sequenced type.
>
> For predefined sets and maps where encounter order corresponds to natural order, 
> there are the following methods in java.util.Collections.
>
> - synchronizedNavigableSet
> - synchronizedNavigableMap
> - synchronizedSortedSet
> - synchronizedSortedMap
>
> However, these methods cannot be used with LinkedHashSet or LinkedHashMap.
>
> The following methods would be useful in order to create thread-safe sequenced 
> collections where encounter order is insertion order, but they are currently not 
> provided.
>
> - synchronizedSequencedCollection
> - synchronizedSequencedSet
> - synchronizedSequencedMap
>
> What are the reasons for or against adding these methods?
>
> There are also no implementations of concurrent sequenced sets and maps where 
> encounter order is insertion order in java.util.concurrent. All of the provided 
> concurrent sequenced sets and maps are based on natural order, and consequently do 
> not support addFirst, and so on.
>
> Are there plans to add concurrent sequenced collections that support the whole 
> interface of sequenced collections?
>
> Kind regards,
> Sebastian