Single Thread Continuation

[Cristian Lorenzetto]

Fibers/continuations are very good but if you are developping a software in
java using many libraries is complicate to realize a optimized software
because third-parties libraries are full of locks thinking to concurrent
working with threads , not fibers. Locks are  time comsuming alot for CPU.
If you use continuations you should  for my opinion review all the code
where you use locks.
In the past i m beginning a project for replacing all the locks with
optimized code for continuation using instrumentation (so also
third-parties libraries get optimized) . No time for finishing.

Il giorno lun 3 lug 2023 alle ore 13:07 Andrii Lomakin <
lomakin.andrey at gmail.com> ha scritto:

> Mark.
> Thank you for raising this point. It is important not only from a gaming
> development perspective, but such an approach could bring benefits in the
> case of database development, too, for the same reason.
>
> On Mon, Jul 3, 2023 at 12:45 PM Mark Raynsford <org.openjdk at io7m.com>
> wrote:
>
>> On 2023-07-02T21:15:29 +0000
>> Ron Pressler <ron.pressler at oracle.com> wrote:
>> >
>> > However, it’s important to remember that our priorities are primarily
>> shaped by Java’s role as a *mainstream* platform and the demands of
>> *mainstream* usages. In other words, what drives up the priority of the
>> feature is not its hypothetical power but its potential use in mainstream
>> applications because that’s where most of the value is, considering the
>> majority of Java’s users. The more mainstream something is, the higher its
>> priority. Given that custom schedulers address less mainstream uses than
>> the default scheduler, they’re on the roadmap but not our highest priority
>> at the moment.
>>
>> I feel obligated to bring this up every time the subject appears: One
>> important use case for me is being able to decompose code into a number
>> of concurrent tasks, but without also having to deal with the
>> complexity of parallelism-related data hazards.
>>
>> In other words, I'd like to be able to use a set of virtual threads
>> that are guaranteed to be scheduled on a single platform thread.
>> This is a common approach used inside language interpreters embedded
>> into game engines (typically Lua, although I hear C# is seeing use for
>> this too nowadays).
>>
>> Game engines and simulations tend to comprise a large number of
>> concurrent tasks, and much of the time those tasks need to access
>> complex mutable state that is very difficult to reliably make
>> thread-safe. Additionally, most of the time it's desirable for it
>> to be possible to pause and resume the execution of individual tasks.
>>
>> Being able to map each task to a virtual thread, but have
>> those virtual threads execute on a single platform thread would
>> solve the problem in a very natural and pleasant way. Additionally,
>> we'd get the ability to pause and resume a task without it losing its
>> stack for free. Normally, that kind of thing has to be implemented
>> manually.
>>
>> I agree it's definitely less mainstream. Most of the code I write isn't
>> like this, but some of it is, and it desperately needs the mechanism
>> that virtual threads don't quite provide yet. An early version did
>> allow for specifying an executor service, but this was obviously taken
>> out.
>>
>> --
>> Mark Raynsford | https://www.io7m.com
>>
>>
>
> --
> Best regards,
> Andrii Lomakin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/9d7fa277/attachment-0001.htm>