> Since aquiring the mutex is already on the 'slow' track,
> couldn't you
> just aquire a second (pointless) mutex inside the first around only the
> 'initialized=1;' assignment? If mutexes resolve the initial situation
> then they must be implemented with a memory fence (in the itanium
> model), and so they should be a high level way to put a memory fence in
> when appropriate - without knowing if they're available on the hardware.
> Andrew

You must acquire a mutex in the fast track. There is no other way to do it
that is portable.

The problem is really this simple -- if the fast track contains no
synchronization primitives, then just because you see 'initialized=1' it
does not guarantee that you will see the changes to the object. A
hypothetical implementation could cache the old values of the memory the
object was in before it was initialized (in a register, in a cache, or in
something that we don't have a word for yet because it doesn't exist yet)
and only invalidate this cache on acquisition of a mutex.

Again, these types of things are platform-specific optimizations for cases
where you know you do not need the full protection of a mutex. However, only
reading and writing the same object under the same mutex actually
*guarantees* (by the definition of a mutex) that you will never go astray.

DCLP is a platform-specific optimization.


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org