This is a discussion on Re: OpenSSL use of DCLP may not be thread-safe on multiple processors - Openssl ; I appologize if this gets posted twice - we've recently changed email addresses company-wide, and my old address is the one that's subscribed to openssl-dev. On Thursday 07 April 2005 19:09, David Schwartz wrote: > > Translation: The compiler can't ...
I appologize if this gets posted twice - we've recently changed email
addresses company-wide, and my old address is the one that's subscribed to
On Thursday 07 April 2005 19:09, David Schwartz wrote:
> > Translation: The compiler can't make assumptions about the state of a
> > variable marked "volatile", and MUST generate code that writes
> > every result
> > stored there as well as code that reads the variable EVERY SINGLE TIME it
> > appears in an expression. It has nothing to do with multi-processor
> > coherency. Any compiler that generates code that deviates from
> > this (even a
> > little bit) isn't compliant with the standard.
> If this were true, every compiler I know of would fail to comply with the
> standard if it didn't bypass any write-back caches on writes to volatile
> variables. After all, those "unknown factors" could modify the memory
> directly, couldn't they?
Nope. The compiler just has to store the variable at what it believes to be
the correct address in memory (and fetch it from there, too) whenever there's
a sequence point in the stream of execution that changes or accesses its
value. It's up to the system as a whole to translate the address into
storage - main, cache, or completely virtual.
This puts restrictions on what the compiler can do in terms of optimizations,
but it doesn't make any assumptions about the underlying system (other than
what's required for the C abstract machine).
As an example of what I was saying - the compiler could translate this code
void foo(int b)
c = b;
a = c;
into an assembly language sequence that loads the contents of b into a
register, and then stores it into both a and c. The following code:
volatile int c;
void foo(int b)
c = b;
a = c;
would require that the compiler generate code that stores the value of b into
c, and then stores the value in c into a. While the compiler would have to
take write reordering into account with respect to this particular process
(or it would violate the requirement that c be written before it's read
again), it's free to ignore caching. It's also free to ignore write
reordering with respect to other processes.
> However, your translation is incorrect. The standard is not talking about
> the compiler, but the system as a whole. It is not saying what the compiler
> must do but what the compiler must emit code to make the system as a whole
> The reason this doesn't require write-back caches to be disabled is
> because the abstract machine doesn't make it clear where the object is. Is
> the object the physical memory chips? The memory as seen through the cache?
> Or what?
Again, I never said anything about caching, since caching is a system feature
that is either transparent (ie - it "just works"), or it requires special
coding techniques that are well beyond the scope of any general language
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com