Single Thread Continuation

[Robert Engels]

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/c7a5eae5/attachment-0001.htm>