From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a7dd909b9ed9f6d5
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-06-26 08:12:25 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!130.133.1.3!fu-berlin.de!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: GNAT: Unbounded_Strings
Date: 26 Jun 2001 17:28:15 +0200
Organization: Enyo's not your organization
Message-ID: <87hex3dzw0.fsf@deneb.enyo.de>
References: <9h9a9n$6bm$1@news.kiev.sovam.com> <87r8w7h8v4.fsf@deneb.enyo.de>
 <873d8nfn0j.fsf@deneb.enyo.de> <9ha4gu$k32$1@news.kiev.sovam.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Xref: archiver1.google.com comp.lang.ada:9118
Date: 2001-06-26T17:28:15+02:00
List-Id: <comp.lang.ada>

"Maxim Reznik" <max1@mbank.com.ua> writes:

> Modifying of a shared string is synchronized by reference counter.
> While this counter >1 any change of shared string can't be done.

Yes, that's necessary for correct operation, and it might be
sufficient if the counter cannot raise after the comparison.

> One thing I could lose sight of is synchronization of counter itself.
> 
> Are following changes enough ?

I'm not sure, I think I would have to see the whole source code.

> I think operators
>++++
>           if Source.Share.Count.Value = 1 then
>                Change_Somehow( Source.Share.Space );
>           else
>                Make_A_Copy
>                Decrement_Count (Source.Share);
>           end if;
>++++

> are Ok, because of Count.Value=1 means that there isn't any other
> references to string and nobody can change neither Share.Count nor
> Share.Space.

I think this agrees with the letter of the ARM.  I'm still not sure if
it breaks any of my expectations regarding string types, but I

> One bad consequence of this solution is 40 bytes overhead for each strings.

You could use one global lock for all reference counter operations.
Contention on this lock isn't a problem when compared to the original
GNAT implementation because all operations which require copying a
string already involve the global allocator lock.