Question about blocking queues and continuations

[Alex Otenko]

Channels in Go are not directly mapped into a BlockingQueue in Java:
channels expose API to select a "read-ready" channel from multiple.

Go doesn't spin up new "Virtual threads". It is subject to the same
constraint: if all channels are not readable, no one is making progress.


Alex

On Wed, 29 Jul 2020, 09:09 , <oliver at objectscape.org> wrote:

> Hello,
>
> I have a question concerning blocking takes from BlockingQueue and
> continuations. Let's say there is a method executed by a virtual thread
> that does blocking takes in a row from two queues:
>
> int queuesSum(LinkedBlockingQueue<Integer> queueOne,
> LinkedBlockingQueue<Integer> queueTwo) {
>   var numOne = queueOne.take(); // 1
>   var numTwo = queueTwo.take(); // 2
>   return numOne + numTwo;
> }
>
> Now, let's assume in the code snippet above queueOne contains an element
> while queueTwo doesn't. So the virtual thread is blocked at queueTwo
> (line 2) until some element is added to it.
>
> I had a short look at Go and from what I understand in the same
> situation as in the code above the Go scheduler has the option to
> withdraw the goroutine from queueSum (you know, in Go a goroutine is
> conceptually what a virtual thread is on Loom).
>
> Let's say all threads the Go scheduler has available to serve goroutines
> are stuck on a blocking takes on channels (a channel in Go is what a
> BlockingQueue is in Java). In that situation the Go scheduler could
> withdraw the goroutine from queueTwo.take() and assign it to some take
> on a channel that is not empty. At least, that is my understand of how
> things work in Go. Once some item is added to queueTwo the Go scheduler
> would assign a goroutine again to queuesSum where it would jump to line
> 2. Continuations in Go would make sure that the goroutine would not jump
> to line 1 and it would make sure that the value stored in numOne from a
> previous method call to queuesSum is remembered.
>
> Problem is now that the Java scheduler that schedules virtual threads in
> Loom has no access to queueTwo as LinkedBlockingQueue is a class in the
> class library. LinkedBlockingQueue is not a language built-in type as
> channels in Go. So the Loom Java scheduler has no way to ask queueTwo
> whether it is empty and therefore there is also no possibility to
> withdraw the virtual thread from line 2 and assign it to some other
> blocking channel as in Go.
>
> Given this situation the Java Loom scheduler could run out of threads
> that serve all virtual threads if queuesSum is called often enough with
> queueTwo every time being empty. As a result the application would run
> out of virtual threads.
>
> So far what I have written is how things work from my understanding I
> have obtained so far. I'm not 100% whether everything is correct. That
> is also why I'm asking my question here.
>
> If everything I have made up so far is correct I could work around this
> problem using ContinuationScope and Continuation:
>
> ContinuationScope scope = new ContinuationScope("queueTwo");
> var numTwo = queueTwo.peek(); // peek() is not blocking
> if(numTwo == null) {
>     Continuation a = new Continuation(scope, () -> {
>         Continuation.yield(scope);
>         numTwo = queueTwo.take(); // blocking take now as we knew that
> queueTwo were no longer empty at this place
>     });
> }
>
> The code above is dummy code to show the intention. I believe it would
> not work like that.
>
> My question is whether I have to do things this way myself with
> ContinuationScope and Continuation or whether Loom would insert that
> continuation itself transparently.
>
> In some presentation of Ron Pressler on Youtube he says that the people
> in the project Loom might decide to lock ContinuationScope and
> Continuation away from the user. It is in question whether those things
> with ContinuationScope and Continuation should happen transparently
> behind the scenes and the user should not have to know about it.
>
> My other question whether some decision has been made on this whether
> ContinuationScope and Continuation will be inaccessible for the user or
> not.
>
> Thanks a lot, Oliver
>