Single Thread Continuation

[robert engels]

The "longer than a word tearing" is a red herring. You will have a data race which is always bad. You can simply not share data across “thread" boundaries without proper synchronization - it doesn’t matter if there is a single thread of execution or not.

If all of the data is write once read many than it doesn’t matter how many threads you use - so that is excluded from the discussion.

Corporative concurrency is a different issue. In this case the developer controls the scheduling by the appropriate yield()/similar statements - so they are in control of the sharing and can ensure there are no data races. And the yield() statement functions as a barrier.

In order to protect against word tearing in the general case you would force all read and writes to be atomic and strict ordering of operations (no compiler or cpu re-ordering) - because you don’t control when the current execution can be interrupted (with preemptive multi-tasking). If you are suggesting that VirtualThreads should not offer preemptive scheduling - I think the experience with Go has proven that to be very difficult in practice - causing all sorts of bugs - because it is not the way developers think of threads.

> On Jul 3, 2023, at 9:05 AM, Mark Raynsford <org.openjdk at io7m.com> wrote:
> 
> On 2023-07-03T07:50:38 -0500
> 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. 
> 
> Which is why I was careful to distinguish between
> parallelism related data hazards (a thread running on one CPU core not
> seeing an update made by a thread on a different CPU core due to
> caches, or only seeing partial updates of larger-than-word-size values
> due to tearing, and etc), and problems of algorithmic correctness (such
> as blindly mutating an account without taking into account [pun not
> intended] that someone else might also be mutating it "concurrently").
> 
> You can eliminate the former as a class of problems and still be left
> with the latter as a different, remaining class of problems: That
> doesn't mean that eliminating the first class has no value.
> 
> I also specifically said that I didn't care about parallelism for this
> particular use case. This is about having an ergonomic programming
> model that plays well with debugging tools, and not about performance.
> If all I cared about was CPU-bound performance, I'd already be using
> platform threads for everything.
> 
> It is absolutely not an impossibility to have a system like this. I've
> written tasking systems by hand in Java that exposed a kind of
> thread-like abstraction with sets of them running on a single platform
> thread. They work, but they're annoying to work with because you lose,
> for example, debugging and local variables (due to not really having a
> stack).
> 
> -- 
> Mark Raynsford | https://www.io7m.com
>