gcc-2.95 and SGI STL 3.2

Dima Volodin dvv@dvv.ru
Tue Jun 22 05:39:00 GMT 1999

On 22 Jun 1999 09:01:25 +0200, Steinar Bang <sb@metis.no> wrote:

>>>>>> dvv@dvv.ru (Dima Volodin):
>> Besides, in a multi-threaded environment, refcounting requires an
>> extra mutex,...
>There's an article by Herb Sutter in the june 1999 issue of the C/C++
>Users Journal
>        http://www.cuj.com/archive/1706/
>(no online version of the article, unfortunately), that addresses
>refcounting in a multithreaded world.  It uses something called
>"atomic integer operations" to do thread-safe refcounting at a lower
>cost than mutex operations.

This is exactly the problem with this approach:

>But as I understand it, these operations may not be available on all
>systems, and if they are, may have different interfaces.

Besides, doing atomic operations is not enough for guaranteeing data
consistency - it's a recurring topic on comp.programming.threads, you
might want to check Dave Butenhof's articles there or just get his book
and see the part about the memory model in POSIX threads.

After some thought given to the subject of <string>, I don't think
anymore that every operation needs mutex locking, but only those which
deal with the ref counter. My guess is these operations are the same as
those explicitly marked in the Standard to invalidate references,
pointers and iterators (21.3/5).

Anyway, having to deal with mutexes breaks the binary compatibility
whichever way you implement it - the inlined code in old libraries won't
know anything about the need to protect ref counters with
synchronization primitives - no matter what these pimitives are.


More information about the Gcc mailing list