Single Thread Continuation

[Andrii Lomakin]

>
> That still seems incorrect to me (in principle, in practice it most likely
> will end up to be fine, but I just wouldn't rely on it), because the
> barrier is needed to prevent instruction reordering by the compiler, and
> you are not safe from that by using the same platform thread.


Wouldn't the usage of locks with plain variables instead of atomic/volatile
and Thread.park/unpark introduce fences while the cooperative nature of
threads would still allow using complex/single-threaded data structures
without fear of breaking data consistency because of the absence of risk of
another thread seeing incomplete operations?

On Mon, Jul 3, 2023 at 1:19 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

>
>> 2. We need to synchronize access to mutable state to avoid memory
>>    hazards. This is a separate issue from synchronizing access to
>>    mutable state to avoid correctness issues. With virtual threads on
>>    a single platform thread, this goes away too (because it's always
>>    the same thread observing memory operations; no barriers needed).
>>
>>
> That still seems incorrect to me (in principle, in practice it most likely
> will end up to be fine, but I just wouldn't rely on it), because the
> barrier is needed to prevent instruction reordering by the compiler, and
> you are not safe from that by using the same platform thread.
>


-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/e8b80c1d/attachment.htm>