From 4901549821157327627
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,25827c9ceb81badc
X-Google-Attributes: gidf78e5,public
From: herbs@cntc.com (Herb Sutter)
Subject: Re: string/cow/algorithm
Date: 1998/08/30
Message-ID: <35e84662.881936868@nr1.toronto.istar.net>#1/1
X-Deja-AN: 386175869
X-NNTP-Posting-Host: 209.89.87.103
Content-Transfer-Encoding: 7bit
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <35D9AE1C.7553@pratique.fr> <35e5e970.464926228@nr1.toronto.istar.net> <6ruqh2$6tc$1@shell7.ba.best.com> <35e47ac7.633205050@nr1.toronto.istar.net> <6s7ejv$q3h$1@shell7.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Organization: iSTAR internet Incorporated
Mime-Version: 1.0
Newsgroups: comp.std.c++
Originator: clamage@taumet


ncm@nospam.cantrip.org (Nathan Myers) wrote:
>Assuming atomic increment, decrement-and-test, and compare 
>instructions for the reference count, no locking need ever be 
>done in a COW implementation (except that done in the memory 
>allocator, used during a deep-copy).  To see this, imagine a 
>string representation object which has one reference.  Clearly 
>there are no thread issues here, and you can operate freely on 
>the string.  

Actually there are thread issues, and what you describe will manifest as
intermittent core dumps -- and, because they're intermittent, ones that
will be difficult to reproduce and difficult to debug.

I originally wrote a long reply here, but instead I'm going to save it
and make this question GotW #43. I should have it posted in a day or
two.

Herb

---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6


[ 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              ]