Memory barriers vs lock/unlock

[Kurt Kohler]

Just a useless comment... Back when I had that weird mutex problem
(thanks again for fixing that!) I noticed this lock/unlock sequence and
was highly puzzled. I showed it to our local multitasking guru and he
didn't understand it either. I'd be interested in hearing why such an
odd looking thing is necessary!

Paolo Carlini wrote:

>Hi,
>
>in our simple port of boost_shared_ptr we have some naively puzzling
>things like:
>
>  void
>  release() // nothrow
>  {
>    if (__gnu_cxx::__exchange_and_add(&_M_use_count, -1) == 1)
>    {
>      dispose();
>      __glibcxx_mutex_lock(_M_mutex);
>      __glibcxx_mutex_unlock(_M_mutex);
>      weak_release();
>    }
>  }
>
>I'm currently investigating that, and I'm not an expert of this area,
>and I'd like to have some help. If I remember correctly some old
>exchanges those "weird" empty lock/unlock stem from the need to add
>memory barriers, nothing more. Therefore, I'm wondering whether we
>wouldn't be best off using right away _GLIBCXX_READ_MEM_BARRIER and
>_GLIBCXX_WRITE_MEM_BARRIER like, for instance, libsupc++/guard.cc is
>already doing. There is a lot to learn from the latter file, more
>generally, in my opinion...
>
>Any quick insight from the gurus?
>
>Paolo.
>  
>