Temporal coupling in Fibers and Fibers vs State Machines.

Mon Feb 24 20:52:54 UTC 2020

Hi Ron,

when I teach or write about concurrent programming, it seems to me that 
programmers tend to be confused about threads and tasks. I try to tell 
them to focus on tasks. Threads and fibers/virtual threads are just a 
mechanism to run tasks. Most programmers should just defer to some 
machinery that maps tasks to whatever is required to run them. With 
fibers/virtual threads, the situation is much brighter than before--one 
can now map lots of tasks that block a lot.

So, my point is that I am long past "blocking is cheap". It's marvelous 
that Loom makes it so, and I appreciate that this is quite a feat of 
engineering.

My hope is that Loom will provide an API for running those tasks in a 
way that makes sense to application developers. The classic thread API 
is not exactly developer friendly, and that's what people see now when 
they investigate Loom.

Perhaps ExecutorService.invokeAll and ExecutorService.invokeAny, when 
used with fibers, could be sufficient for structured concurrency. But it 
appears to be an awkward API.

A few iterations ago, you had a more compelling API, and I look forward 
to seeing more work on that.

There will always be the state machine enthusiasts, but if Loom could 
nail the equivalent of invokeAll and invokeAny, with cancellations, 
durations/timeouts, and resource cleanup, that would take care of a lot 
of use cases.

Cheers,

Cay

Il 24/02/20 18:57, Ron Pressler ha scritto:
> Loom adds a lightweight implementation of threads, similar to how 
> ArrayList and
> LinkedList are two implementations of List with different performance 
> characteristics.
> True, often a difference in implementation can change coding practices. 
> After all,
> people avoid blocking threads not because of the abstraction but because 
> of the
> implementation, but I am not sure what kind of confusion this causes.
> I cannot see in what way, other than implementation, a fiber is 
> different from a thread,
> so I am not sure what the two concepts you’d like to see separated are. 
> Could
> you explain?
> 
> As to the "promise of Loom", let me try to put it like this: think of 
> all the code patterns,
> libraries etc. made to avoid creating and blocking threads. Now think 
> what it means if
> creating and blocking a thread is cheap.
> 
> - Ron
> 
> 
> On 24 February 2020 at 14:28:00, Cay Horstmann (cay.horstmann at gmail.com 
> <mailto:cay.horstmann at gmail.com>) wrote:
> 
>> Here is an article that goes into some depth of pros and cons of fibers:
>> https://blog.softwaremill.com/will-project-loom-obliterate-java-futures-fb1a28508232 
>>
>>
>> I guess right now, without the structured concurrency API, it really
>> isn't so easy to see the promise of Loom. The "let's make fibers look
>> like threads" approach might add to the confusion.
>>
>> Cheers,
>>
>> Cay
>>
>>
>> Il 23/02/20 08:32, Rahul Khandelwal ha scritto:
>> > Hi Dávid,
>> >  
>> > Thanks for the explanation.
>> >  
>> > I have a little experience with Kotlin Coroutines and you are right in
>> > saying that composition have to be taken care in the source code itself. It
>> > could be argued that reactive APIs are much more easier to use in that
>> > sense.
>> >  
>> > It is also true that when using reactive APIs, Developers don’t have to
>> > deal with low level constructs like atomics, locks, etc. This doesn't look
>> > same in case of virtual threads, Virtual threads looks pretty much same as
>> > normal threads when dealing with shared resources. correct me if I got it
>> > wrong here.
>> >  
>> > About the sales pitch of loom, I can see the same thing. When I started
>> > following loom few years back, it was proposed as a solution where you can
>> > write imperative code and get the performance on par with reactive code. It
>> > actually felt like JVM will do the heavy lifting and API users won't have
>> > to deal with it. It is really hard to get concurrency right in Java and
>> > even after loom it looks like that users will have to rely on DIY solutions
>> > or third party libraries to get things right.
>> >  
>> > Thanks,
>> > Rahul
>> >  
>> >  
>> > On Thu, Feb 20, 2020 at 1:12 AM Dávid Karnok <akarnokd at gmail.com> wrote:
>> >  
>> >> Rafael's concerns are mostly related how the functional and declarative
>> >> nature of the reactive libraries are difficult to learn for some people.
>> >> Yet, these people happily code in SQL and use Java Streams. Maybe it's time
>> >> to go back to reading database files with InputStream and use for loops as
>> >> well.
>> >>
>> >> Martin's concerns are, if by composition he means what I think he means,
>> >> if you could set up pieces of computation and functionality and combine
>> >> them into larger components. If so, these components can have state and
>> >> those state could change in response to stimuli from other components.
>> >> Reactive is one of such approach that has individual pieces - operators
>> >> chained up on a dataflow have internal state tracking when and how their
>> >> peers can send data and commands to each other. Loom's, and Kotlin's
>> >> Coroutines instead say you compose via the source code itself, by writing
>> >> larger and larger methods encompassing a lot of imperative operations. If
>> >> you have such a method, but for some uses need some retry code, you may be
>> >> out of luck and have to code yet another set of methods to include that
>> >> functionality.
>> >>
>> >> Vaughn's concerns are that there aren't many helping hands with Fibers and
>> >> concurrency. In fact, you have to consider the Java Memory Model again the
>> >> moment two routines in separate fibers have to communicate: blocking
>> >> structures, atomics, locks and their effects on visibility. In reactive,
>> >> from an user's perspective, you don't have to worry about most of these as
>> >> the libraries can hide many of the intricacies of the JMM and provide you
>> >> with an API and callback surface. Want to create an item and hand it over
>> >> to another thread for processing? There are operators for that and you have
>> >> only to specify how to create the item, what thread it should end up and
>> >> what processing there should be for it. Want to generate many items?
>> >> Replace the front of the flow and the rest will still be the same.
>> >>
>> >> Also note that Loom's sales pitch has shifted over the years. It started
>> >> as the solution that will outperform reactive and having users code in easy
>> >> to understand imperative fashion as the JVM will do the heavy lifting
>> >> behind the scenes. However, we have pointed out that a) suspension is more
>> >> costly and may dominate the overheads, b) composition (see above) is
>> >> limited so people, individually and over and over, may end up with DIY
>> >> solutions and c) you have to make sure locks/blocking happen in a virtual
>> >> thread for which you may have to inject virtual thread-based executors all
>> >> over the place.
>> >>
>> >> Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2020. febr.
>> >> 19., Sze, 19:48):
>> >>
>> >>>
>> >>> Hi.
>> >>>
>> >>> I don’t think I really understand what the concerns are, and believe they
>> >>> might
>> >>> be tied to a misunderstanding of Loom’s goals and design.
>> >>>
>> >>> Anyone who has concerns is welcome to explain them here, without
>> >>> character-count limits.
>> >>>
>> >>> Ron
>> >>>
>> >>>
>> >>>
>> >>> On 19 February 2020 at 18:37:53, Rahul Khandelwal (rahulnewai at gmail.com
>> >>> (mailto:rahulnewai at gmail.com)) wrote:
>> >>>
>> >>>> Hi All,
>> >>>>
>> >>>> I have been following Project Loom for quite some time now and I find it
>> >>>> really exciting.
>> >>>> This is my first post in the mailing list.
>> >>>>
>> >>>> I went through the following twitter discussion -
>> >>>> https://twitter.com/rafaelcodes/status/1176229314112741377
>> >>>> However I could not understand the final gist/conclusion of the
>> >>> discussion.
>> >>>>
>> >>>> 1. Here In the discussion Martin Thompson had the view that Fibers don't
>> >>>> compose and cannot escape temporal coupling.
>> >>>> He also advocated about the use of explicit state machines instead of
>> >>>> Fibers.
>> >>>> https://twitter.com/mjpt777/status/1176231250308325376
>> >>>>
>> >>>> 2. Vaughn Vernon had opinions around the Java memory model and the
>> >>>> complexity of the effects of predictive execution.
>> >>>> https://twitter.com/VaughnVernon/status/1176299015849136128
>> >>>>
>> >>>>
>> >>>> Could someone explain what were the concerns and suggestions they
>> >>> expressed
>> >>>> and how Fibers handle said concerns.
>> >>>>
>> >>>> It would be great if someone could suggest some resources to better
>> >>>> understand above twitter discussion.
>> >>>>
>> >>>>
>> >>>> Thanks,
>> >>>> Rahul
>> >>>
>> >>>
>> >>
>> >> --
>> >> Best regards,
>> >> David Karnok
>> >>