More on memory barriers

[Jason Merrill]

On Wed, 15 Sep 2004 00:17:41 -0700, Richard Henderson <rth@redhat.com> wrote:

> On Wed, Sep 15, 2004 at 02:22:03AM -0400, Jason Merrill wrote:
>> if (!initialized)
>>   {
>>     acquire_lock();
>>     if (!initialized)
>>       {
>>         initialize ();
>>         memory_barrier(); // force serialization on all CPUs
>>         initialized = true;
>>       }
>>     release_lock();
>>   }
>> 
>> On Alpha we need a second memory barrier, i.e.
>> 
>> else
>>   read_memory_barrier ();
>
> Well, no, Alpha needs
>
>   read_memory_barrier ();
>   if (!initialized)
>[...]

Hmm?  Why do we need the read barrier on the initialization path?  I would
expect the mutex to provide enough of a read barrier.

>> On ia64, does a release barrier have the desired semantics, or do we
>> need a full barrier?
>
> Release is sufficient.  In particular, the barriers that must be
> present for the lock release are sufficient to ensure that the
> read of initialized happens after the write.
>
> We do still need a write_memory_barrier here.  For that,
> __sync_synchronize is still the best implementation available.

By "release barrier" I meant annotating the assignment to initialized with
.rel, which I would expect to be less expensive than __sync_synchronize.
But you would know better than I.

Jason