This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Memory barriers vs lock/unlock
- From: Paolo Carlini <pcarlini at suse dot de>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>,Peter Dimov <pdimov at mmltd dot net>
- Date: Tue, 08 Nov 2005 14:57:28 +0100
- Subject: Memory barriers vs lock/unlock
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.