[concurrency-interest] Fire and forget api for queing vs. BlockingQueue interface (TransferQueue will be inefficient?)
dl at cs.oswego.edu
Sun Mar 1 14:47:04 EST 2009
Taylor Gautier wrote:
> What I mean specifically is that the presence of the consumer operations
> in the interface forces the queue to always maintain a consistent state
> - on both "sides" of the "fence" (fence meaning thread boundary, in
> Terracotta, it's a process boundary usually)
This is a tradeoff in API design, that I've
done both ways (and both multiple times). Is a Queue more
like a Socket end-point or more like a List? Either way you go,
someone is unhappy. Many people complained about my pre-j.u.c.
(dl.u.c) "Channel" API because it was too socket-like and
not enough List-like.
The best defense of using the more encompassing Collection-based
approach is that people building middleware can use it underneath
their own abstractions to implement within-process cases
efficiently, but only if they don't further expose/export the APIs.
I think this is what most people do.
Terracotta ambitiously goes beyond this, to support full APIs across
process boundaries, which is going to be even more challenging
as parallelism support becomes increasingly fine-grained. I don't
know what we can do in java.util.concurrent to make it any less so
More information about the Concurrency-interest