This is a discussion on RE: OpenSSL use of DCLP may not be thread-safe on multiple processors - Openssl ; > 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 ...
> 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.
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 firstname.lastname@example.org
Automated List Manager email@example.com