On 29 December 2010 02:17, Filip Hanik - Dev Lists <devli...@hanik.com> wrote: > > > On 12/28/2010 5:02 PM, sebb wrote: >> >> On 22 December 2010 16:04, Filip Hanik - Dev Lists<devli...@hanik.com> >> wrote: >>> >>> On 12/21/2010 7:29 PM, sebb wrote: >>>>> >>>>> - private long signal; >>>>> + private volatile long signal; >>>> >>>> It would be cheaper to make it final as it's only ever set in the ctor >>>> and is immutable. >>> >>> nothing cheaper, volatile are only expensive to write, not read. >> >> That's not my understanding of how volatile works. > > there is a great book on concurrency that explains how the bus and cpu > architectures handle these, if I remember the title of it, I will send it to > you
Please do. I've worked on HP Alpha shared memory systems where writes by one processor may be seen in a different order on another; it would be interesting to see how this is treated in the book. >> >> AIUI, the reader thread always needs to refresh the value of the field >> in case another thread has updated it. >> >> Whereas a final field can be safely cached in local memory. >> As you write above, the volatile qualifier affects how the compiler handles writes. However, the volatile qualifier also affects read operations. The JMM allows threads to cache values in local memory; also shared memory may need memory barriers to ensure the reader sees what the last writer wrote. The volatile qualifier means that the compiler has to generate extra instructions to ensure that the value - whether cached or not - is current. On the other hand, the value of a final field can safely be cached. The compiler can just use the cached - or shared - value directly. [Furthermore, Java 1.5+ compilers are not allowed to reorder certain operations with respect to volatile reads. This may also impact performance.] >>> If maxConnections becomes a dynamically adjustable attribute, so will >>> this one >>> have to be. >> >> True, but at present it is immutable. >> >>>>> private volatile boolean released = false; >>>>> >>>>> /** >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 10.0.1170 / Virus Database: 1435/3329 - Release Date: 12/21/10 >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
