tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1051539 - /tomcat/trunk/java/org/apache/tomcat/util/threads/CounterLatch.java
Date Thu, 30 Dec 2010 14:28:47 GMT
On 29 December 2010 02:17, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>
>
> On 12/28/2010 5:02 PM, sebb wrote:
>>
>> On 22 December 2010 16:04, Filip Hanik - Dev Lists<devlists@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message