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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,229ea0001655d6a2
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news2.google.com!news.glorb.com!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!xara.net!gxn.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail
From: Simon Wright <simon.j.wright@mac.com>
Newsgroups: comp.lang.ada
Subject: Re: Generic Package
Date: Fri, 27 Apr 2007 22:16:35 +0100
Organization: Pushface
Message-ID: <m2mz0tcybw.fsf@mac.com>
References: <1177539306.952515.222940@s33g2000prh.googlegroups.com>
 <1177601484.444701.171560@r35g2000prh.googlegroups.com>
 <pcp92sp50q98$.lad523qlftgm.dlg@40tude.net> <m2zm4udcqt.fsf@mac.com>
 <degsdvcu9wwi$.1j7dffe23bgq5$.dlg@40tude.net>
 <1177672290.8055.6.camel@localhost>
 <ozslghlwuydt$.1t30ht6ytimwi$.dlg@40tude.net> <m2r6q5d2lu.fsf@mac.com>
 <yjlq1yqm0bl1.14lagjp35o64c$.dlg@40tude.net>
NNTP-Posting-Host: pogner.demon.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.demon.co.uk 1177708595 3260 62.49.19.209 (27 Apr 2007 21:16:35
 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Fri, 27 Apr 2007 21:16:35 +0000 (UTC)
Cancel-Lock: sha1:Ke+VkbdTGgiq1uaQOGkqXho1vvs=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (darwin)
Xref: g2news1.google.com comp.lang.ada:15367
Date: 2007-04-27T22:16:35+01:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 27 Apr 2007 20:44:13 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 27 Apr 2007 13:11:30 +0200, Georg Bauhaus wrote:
>> 
>>>> Any real table in an existing computer has a "natural"
>>>> ordering suitable for iterating an operation for all
>>>> elements: data in a real computer can be uniquely identified.
>>>
>>> No this is wrong even on a real computer. The DB engine could
>>> shuffle the rows asynchronously to your application. There could be
>>> other applications playing with the table. The table might spread
>>> over memories of several computers and different levels cashes. You
>>> have to bring transactions, replications and other synchronizing
>>> stuff to make any sense out of "natural order."
>> 
>> Just using ordered containers is hardly going to stop you needing to
>> deal with locking!
>
> In some sense it would. Provided it existed unconditionally, you would not
> need to lock anything. Because otherwise any relevant change would destroy
> the order in contradiction to the premise. Obviously you don't need to lock
> if possible changes wouldn't affect the order.

I can't imagine any sense in which it could. Perhaps you're thinking
of special hardware that could have these properties? But that's just
devolving the concurrency problem to an engineer in another
discipline.