CODEWITHSUNDEEP
javaconcurrency
Guillaume
Guillaume

Reputation: 5557

Is there an existing implementation of a FilteringBlockingQueue in a 'generally accepted' library (Jakarta Commons, Guava, Spring, ...?)

There is the PriorityBlockingQueue in the jdk, that is able to sort the elements with a (provided or default) Comparator.

Now I need a FilteringBlockingQueue, that is a concurrent Queue that offers at a given point in time only a subset of elements based on a dynamic filter and for which the poll operation doesn't remove the element but change it's state.

Changing the state of the element should also results in a signal so that any thread waiting (within a poll() call) would be able to get the item and continue.

The idea is to keep a single concurrent collection with different partitions, each of these partitions being a subset of element with the same state.

The polling should be done by passing the predicate and the mutator that will move the element to another partition in the same atomic operation.

Is such a thing already exists in a 'standard' library (and does it has a known name) ?

edit: I found a similar request here: Java Blocking List Implementation but without any accepted answer...

Upvotes: 0

Views: 61

Answers (1)

tucuxi
tucuxi

Reputation: 17945

The question is similar to asking for a FilteringStack: if different users of the data-structure, by using different filters, see radically different behavior (for example, each one sees a different top-of-the-stack), is it really a Stack? Classic data-structures (and their concurrent versions) have well-defined semantics and well-known optimal implementations. If you change the semantics, those implementations will no longer work.

If you need to change ordering and filters at run-time and per-thread, in a thread-safe way, I would recommend using an in-memory database such as HSQLDB, H2 or Derby. You can also avoid the overhead of mapping from object to relational formats and vice-versa by using objectdb instead.

Alternatively you can write your own implementation, but beware that fast & safe multi-threaded code is famously hard to write. I would only write it once it was clear that performance was actually a bottleneck.

Upvotes: 1

Related Questions