<div dir="ltr"><div dir="ltr">Andrii Lomakin <<a href="mailto:lomakin.andrey@gmail.com">lomakin.andrey@gmail.com</a>> ezt írta (időpont: 2023. júl. 3., H, 15:13):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div> </div><div>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?</div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div>