Single Thread Continuation

Attila Kelemen attila.kelemen85 at gmail.com
Mon Jul 3 13:18:44 UTC 2023


Andrii Lomakin <lomakin.andrey at gmail.com> ezt írta (időpont: 2023. júl. 3.,
H, 15:13):

> 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?
>
>
It would, but if you are correctly synchronized with locks or whatever
else, then it doesn't matter if you are running on the same carrier thread
or not. I just simply don't see any case, where code is correct when having
a single platform thread running multiple VTs is, while it is incorrect
with multiple carrier threads.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/5944566c/attachment.htm>


More information about the loom-dev mailing list