Single Thread Continuation

[Øystein Myhre Andersen]

Hi, if it's of interest, here is my implementation of Coroutine.java:

https://github.com/portablesimula/SimulaCompiler/blob/master/Simula/src/simula/runtime/Coroutine.java


- Øystein Myhre Andersen

On Mon, Jul 3, 2023 at 3:05 PM Robert Engels <rengels at ix.netcom.com> wrote:

> To elaborate a hit on why the single threaded task executor does not solve
> the concurrency problem.
>
> Imagine your tasks are “get account balance” and “set account balance” and
> these are available to external actors. You still need “lock account” and
> “unlock account” to make the system correct.
>
> Yes, you could instead write an atomic “get and update account” but this
> isn’t always possible.
>
> The premise that making something single threaded removes concurrency
> issues is false.
>
> On Jul 3, 2023, at 7:51 AM, Robert Engels <rengels at ix.netcom.com> wrote:
>
> 
> That is an impossibility in Java. It is a shared memory system so you can
> not have guaranteed parallelism without concurrency concerns. If you
> guarantee to write your tasks in a concurrency safe way -you can already
> control the number of carrier threads.
>
> If is similar to Python - Python is single threaded (typically) but you
> can create multiple “threads” - and you still need to use locks to control
> access to shared data.
>
> Same with JavaScript (might be a better example).
>
> On Jul 3, 2023, at 7:39 AM, Mushtaq Ahmed <mushtaq.a at gmail.com> wrote:
>
> 
>
>> 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.
>
>
> Thanks for articulating this so well. This is the exact use case we have.
>
> I was very excited to read about the following API in early loom
> prototypes but it did not make it in the final release:
>
> Thread.builder().virtual(Executors.newSingleThreadExecutor()).factory()
>
> Loom getting custom schedulers which allow this will be a big deal.
>
>
> On Mon, Jul 3, 2023 at 4:15 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/4085d026/attachment-0001.htm>