On 3/28/07, Darryl Miles <[EMAIL PROTECTED]> wrote:
Actually 'volatile' doesn't provide a useful fix.
[...]
>> The problem occurs after the beginning of the function. If the compare is
>> done on a cached copy in a register. Look at this example:
>>
>> if (variable!=NULL)
>> {
>> free(variable);
>> variable=NULL;
>> }
>>
>> This could easily be optimized to (cached_copy is a register or other
>> fast
>> place to store data):
>>
>> int cached_copy=variable;
>> if(cached_copy!=NULL)
>> {
>> acquire_lock();
>> cached_copy=variable;
>> free(cached_copy);
>> cached_copy=NULL;
>> variable=cached_copy;
>> release_lock();
>> }
>> else variable=cached_copy;
>>
>> If you think this cannot happen, I defy you to explain to me why. What
>> standard or guarantee is being violated? How can POSIX-compliant or
>> C-compliant code break with this optimization? How can you say it can
>> never
>> be faster?
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in "cheap-to-access" locations
like registers, instead being re-loaded from "expensive-to-access"
locations like the original memory -- because it may be changed from
outside the control flow that the compiler knows about.
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
