{"id":212,"date":"2008-06-29T17:18:19","date_gmt":"2008-06-29T17:18:19","guid":{"rendered":"https:\/\/kari.world.ikari.fi\/2008\/06\/29\/but-it-works-on-my-machine\/"},"modified":"2008-06-29T17:18:19","modified_gmt":"2008-06-29T17:18:19","slug":"but-it-works-on-my-machine","status":"publish","type":"post","link":"https:\/\/kari.world.ikari.fi\/?p=212","title":{"rendered":"But It Works On My Machine&#8230;"},"content":{"rendered":"<p><a href=\"http:\/\/java.dzone.com\/articles\/but-it-works-on-my-machine\">But It Works On My Machine&#8230;<\/a><\/p>\n<p>As summary: difference between &#8221;server&#8221; and &#8221;client&#8221; JVM *can* cause big surprises in badly coded thread stop conditions. Additionally other random synchronized blocks can cause unpredictability in behaviour.<\/p>\n<p>I tested sample program, and there really was this big difference between &#8221;-client&#8221; and &#8221;-server&#8221;. Changing &#8221;stopRequested&#8221; to be volatile caused consistent behaviour in both JVMs. And no, my computer isn&#8217;t even having fancy multithreaded or multicore CPU.<\/p>\n<p>Naturally this issue concerns not only stop condition of the thread, but <b>all<\/b> member fields accessed from the worker thread. If there is no sync, then worker thread is not seeing changes in the values immediately.<\/p>\n<p>So, you have been warned. Don&#8217;t trust into those pesky non-synced stop flags to work, or you will be bitten by &#8221;but it worked in my computer&#8230;&#8221; syndrome.<\/p>\n<p>Note: Of course this &#8221;proof of the problem&#8221; test program is a bit flawed. Server JVM is doing high optimization for the loop construct, and thus doesn&#8217;t check change of the field, since there isn&#8217;t some &#8221;sync&#8221; to enforce such. However, such buzy loops without some random syncronization block to occur are rather rare in normal worker threads.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>But It Works On My Machine&#8230; As summary: difference between &#8221;server&#8221; and &#8221;client&#8221; JVM *can* cause big surprises in badly coded thread stop conditions. Additionally other random synchronized blocks can cause unpredictability in behaviour. I tested sample program, and there really was this big difference between &#8221;-client&#8221; and &#8221;-server&#8221;. Changing &#8221;stopRequested&#8221; to be volatile caused&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-212","post","type-post","status-publish","format-standard","hentry","category-java"],"_links":{"self":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts\/212","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=212"}],"version-history":[{"count":0,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=\/wp\/v2\/posts\/212\/revisions"}],"wp:attachment":[{"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kari.world.ikari.fi\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}