Kyle Hamilton wrote:
On 3/28/07, Darryl Miles <[EMAIL PROTECTED]> wrote:
>> 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.
Agreed with the sorts of things volatile inhibits.
But this whole tangent is irrelevant to the original posters code. The
above pseudo code is not a valid interpretation. The last line David
wrote "variable=cached_copy;" can't happen for the code:
if(variable) {
free(variable);
variable=NULL;
}
Like David has claimed.
A compiler will not generate a store instruction to put back a
"cached_copy" into the variable location. Principally because there was
no assignment operation in the original code and because even a
non-optimizing compiler knows it can just dump the "cached_copy"
temporary register on the floor.
The conversation stemmed from the code:
1289 if (ssl_comp_methods == NULL)
1290 return;
1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL);
1292 if (ssl_comp_methods != NULL)
1993 {
...SNIP...
1296 }
1297 CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
If ssl_comp_methods is NULL, then no store instruction to the memory
location of ssl_comp_methods will ever happen. So nothing is subject to
the so called "lost write" concurrency problem.
So marking it 'volatile' will not gain the above code anything. But it
will inhibit valid optimizations the compiler might make to all code
that uses the variable 'ssl_comp_methods' that are inside the locked
regions.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
