From 408365306964072240
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,25827c9ceb81badc
X-Google-Attributes: gidf78e5,public
From: phalpern@truffle.ma.ultranet.com (Pablo Halpern)
Subject: Re: string/cow/algorithm
Date: 1998/08/25
Message-ID: <35db79a9.10154094@news.ma.ultranet.com>#1/1
X-Deja-AN: 384609810
X-NNTP-Posting-Host: truffle.ultranet.com
Content-Transfer-Encoding: 7bit
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <35D9AE1C.7553@pratique.fr> <35dc79ad.108635599@nr1.toronto.istar.net> <6rplfg$m3q$1@shell7.ba.best.com> <35e5e970.464926228@nr1.toronto.istar.net>
X-UID: 0000000001
X-Status: $$$$
X-Ultra-Time: 25 Aug 1998 16:03:55 GMT
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@ultra.net
Organization: UltraNet Communications , an RCN Company http://www.ultranet.com/
Mime-Version: 1.0
Newsgroups: comp.std.c++
Originator: clamage@taumet


herbs@cntc.com (Herb Sutter) wrote:

>Operating on the reference count is immaterial; I assume that's fast. The
>number of locks required is material, because locks are expensive:
>
>1. The string still has to acquire the memory manager's lock when actually
>making a copy. Any additional COW-induced overhead is in addition to that
>lock, not instead of it.

Of course. But since COW requires fewer copies, this should be a net win
over performing deep copies every time.

>2. The string must additionally acquire a lock for at least each possibly
>mutating operation -- meaning not just copy operations, but also accessors
>and mutators. Hence this locking is far more frequent than copies in the
>common case.

I don't think this is true. Before modifying a buffer, the buffer must
not be shared (definition of COW).  An unshared buffer need not be mutex
locked.  If the reference count indicates that the buffer is not shared,
the only way it can be incremented is by copying the only string that
references it. If one thread is trying to read (or copy) the string
while another is modifying it, you have a BUG IN THE PROGRAM, not a bug
in the string class. If two threads access a shared string, they should
use a mutex lock EXTERNAL TO THE STRING ITSELF. 

I don't think it is a good specification for strings that every
operation be considered atomic.  If you design every method of every
class to be atomic, your MT program is likely to get bogged down in
mutex locking, even for unshared resources.  It may allow sloppy
programs to work correctly, but it is not the way to go if you want
efficiency.  Strings in which every opration is logically atomic should
be a different class (e.g. inter_thread_string).

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]