<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">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.</blockquote><div><br></div><div>Well if we use long as a state instead of long with atomic operations will cause the code to be correct in a single carrier and incorrect in the case of many carriers :-) </div><div>If someone wants to go into such subtle optimization.</div><div>But putting jokes aside, probably I was wrong in understanding the needs of the game development area but the main point was that you can work with complex structures otherwise it would not be possible to use without the cooperative nature of threads. </div>And that is quite an interesting case. There are probably not as many game developers or database developers in the Java world as one might think, but the number is also not insignificant.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 3, 2023 at 3:18 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:<br></div><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"><div dir="ltr">Andrii Lomakin <<a href="mailto:lomakin.andrey@gmail.com" target="_blank">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>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Best regards,<br>Andrii Lomakin.<br><br></div></div></div></div>