Re: java.util.concurrent.Flow with opposite direction of item flow

How can it be both
Blocking and Async?

I think there is some misalignment with the intended uses of Producer and
Consumer. The whole idea behind Flow protocol is that both Producers and
Consumers are backpressure-aware. But the Blocking Queue in the middle
implies that you want a Producer that is not backpressure-aware, so back
pressure is essentially implemented through blocking.

Alex


On Thu, 19 Dec 2019, 14:24 Alexei Kaigorodov via Concurrency-interest, <
[email protected]> wrote:

> Consider the following structure of a multithreaded program:
>  - a single BlockingQueue
> - several Producer threads which push their results to the queue
> - several Consumer threads which take items from the queue
>
> Now I want to replace some of the Producers and Consumers with their
> asynchronous analogs: AsyncProducer and AsyncConsumer.
> First, I need to add asynchronous interfaces to the BlockingQueue, making
> it
> AsyncBlockingQueue. As a base, I can use my own implementation, not those
> from java.util.concurrent.
> For interaction between AsyncBlockingQueue and AsyncConsumer interfaces
> from
> java.util.concurrent.Flow are sutable: AsyncBlockingQueue implements
> Flow.Publisher and AsyncConsumer implements Flow.Subscriber.
> But for communication between AsyncProducer and AsyncBlockingQueue
> java.util.concurrent.Flow is not sutable.
> Let AsyncProducer implements  Flow.Publisher and AsyncBlockingQueue
> implements Flow.Subscriber.
> Then, when the queue has room to store items, it should call
> Flow.Subscription#request(n), where sum of all arguments 'n' shoud not
> exceed the amount of available memory.
> But as there are many subscriptions, which subscriptions to choose?
> The queue should know which AsyncProducers are ready to submit data,
> otherwise, the resource of its buffer memory is wasted.
> The evident solution to this problem is, Producers must play active role
> and
> so be like Subscribers, able to call Subscription#request() at their own
> discretion,
> Such a protocol I named ReverseFlow (native English speakers are invited to
> propose a better name).
> It is published  at
> https://gist.github.com/akaigoro/9506659d7d87a85a2a58a647405d85d6
>
> So I'd like to propose to include ReverseFlow interfaces in JDK, and
> provide
> a reference implementation of AsyncBlockingQueue interface, which extends
> BlockingQueue, ReverseFlow.Publisher, and Flow.Publisher.
>
>
>
>
>
>
> --
> Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest