On 18/06/2009, Mark Thomas <ma...@apache.org> wrote: > Tim Funk wrote: > > I think this needs to be volatile ? > > In (GetDateBenchmarkTest) > >> + private long currentMillis = 0; > > > > Same for (in TimeDateElementBenchmarkTest) > >> + private Date currentDate = null; > > > > Of course - since the test is single threaded - it doesn't really matter. > > > The test should be multi-threaded unless I got something badly wrong. I'll > double check. > > Making those volatile gets them closer to the real code. I doubt it will > make a > difference but worth changing to be sure. You never know with these things.
The field GetDateBenchmarkTest.currentDate is set in a synch. block in doSynch(), but for the return it is fetched outside the synch. block - so it could potentially be changed by another thread. Also if the synch. block is not entered, the thread might not see the correct version of the field as there is no synch. on the read. Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the field is volatile, it is set in the synch. block but fetched for the return outside the block. If it is intended to allow currentDate to be updated by another thread before the return, then the field needs to be volatile. Otherwise the return value needs to be established in the synch. block. > Mark > > > > > > -Tim > > > > ma...@apache.org wrote: > >> Author: markt > >> Date: Thu Jun 18 08:32:29 2009 > >> New Revision: 785952 > >> > >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev > >> Log: > >> Add some micro-benchmarks that enable the differences between the Sync > >> and ThreadLocal approach to be compared > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
