Comments on: Java concurrency refcard! http://tech.puredanger.com/2009/07/06/java-concurrency-refcard/ Alex Miller's technical blog Wed, 28 Jul 2010 22:41:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Alex http://tech.puredanger.com/2009/07/06/java-concurrency-refcard/comment-page-1/#comment-170539 Alex Tue, 14 Jul 2009 06:17:23 +0000 http://tech.puredanger.com/2009/07/06/java-concurrency-refcard/#comment-170539 Thanks Ruben. You are correct although this is something that should clearly be documented and creates a constraint on any other code that is updating the flag as well. Thanks Ruben. You are correct although this is something that should clearly be documented and creates a constraint on any other code that is updating the flag as well.

]]> By: Ruben http://tech.puredanger.com/2009/07/06/java-concurrency-refcard/comment-page-1/#comment-170391 Ruben Mon, 13 Jul 2009 10:54:06 +0000 http://tech.puredanger.com/2009/07/06/java-concurrency-refcard/#comment-170391 Hi, That refcard of yours is truly awesome. One question: In the example of the "Thread Coordination" section, the boolean instance member <i>flag</i> does not need to be volatile, does it? AFAIK, the update in <i>change()</i> is gonna be flushed to main memory and picked up by any subsequent invocation to <i>waitTillChange()</i> because they are properly synchronized by the monitor associated to <i>lock</i>. Thanks. Hi,

That refcard of yours is truly awesome. One question:

In the example of the “Thread Coordination” section, the boolean instance member flag does not need to be volatile, does it? AFAIK, the update in change() is gonna be flushed to main memory and picked up by any subsequent invocation to waitTillChange() because they are properly synchronized by the monitor associated to lock.

Thanks.

]]>