Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Address space limits
Date: Sun, 5 May 2024 17:38:15 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <v198pm$259jc$2@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me>
 <62dff0b888855a31ec10c0597669423f@www.novabbs.org>
 <v0soai$30rmc$3@dont-email.me>
 <f2ac45ffe1718a0b0070f027f0e5f58c@www.novabbs.org>
 <20240501225652.00002853@yahoo.com>
 <jwvh6fhnuzu.fsf-monnier+comp.arch@gnu.org> <v0uppp$3fitf$2@dont-email.me>
 <v1521l$15g68$1@dont-email.me> <v16b3u$1dm6l$2@dont-email.me>
 <9e81a0aa95b5eae7ae6fc9f99455df97@www.novabbs.org>
 <v16u6q$1lbg7$1@dont-email.me>
 <bee5c0c86431e8e6081b092490c70b95@www.novabbs.org>
 <v198k5$259jc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 06 May 2024 02:38:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cff0ec37b077e4ecd6d3da1f27c1fc18";
	logging-data="2270828"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19VTTetpeI8PXhyES44uRsXXMM/ZrSR0zw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Em42JsBTZny+u867qdbuAMyP8VE=
Content-Language: en-US
In-Reply-To: <v198k5$259jc$1@dont-email.me>
Bytes: 3982

On 5/5/2024 5:35 PM, Chris M. Thomasson wrote:
> On 5/5/2024 3:25 PM, MitchAlsup1 wrote:
>> Chris M. Thomasson wrote:
>>
>>> On 5/4/2024 5:12 PM, MitchAlsup1 wrote:
>>>> Chris M. Thomasson wrote:
>>>>
>>>>> On 5/4/2024 3:18 AM, Thomas Koenig wrote:
>>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>>>>>
>>>>>>> Intel pushed this thing called the “x32” ABI into the Linux kernel
>>>> (and
>>>>>>> possibly some other places) some years ago. This was using the AMD64
>>>>>>> instruction set, but with only 32-bit pointers. This way, you got 
>>>>>>> the
>>>>>>> benefit of the extra registers, without the overhead of the longer
>>>>>>> addresses.
>>>>>>
>>>>>> That was Donald Knuth's idea.
>>>>
>>>>> Storing meta data in actual pointers, aka aligned on a larger 
>>>>> boundary, is critical to many advanced lock/wait free algorithms as 
>>>>> well. I remember storing an actual reference count in pointers 
>>>>> before for a special type of counting.
>>>>
>>>> Even if one has multi-location ATOMICs ?? (as a single event ??)
>>
>>> This was a technique for storing data in a pointer. For instance, 
>>> strong atomic reference counting we need to update a pointer _and_ a 
>>> reference together atomically. This can easily be done with DWCAS, or 
>>> double width compare and swap. So, on a 32 bit system we need 64 bit 
>>> cas, for a 64 bit system we need 128 bit cas. However, sometimes we 
>>> can pack the reference count in the pointer value itself if its 
>>> aligned on a big enough boundary. Then we can update the pointer and 
>>> the reference count using normal word based atomic RMW's.
>>
>> I understand why you had to pack the pointer and a chunk of data into a
>> single container.
>>
>> What I don't understand is if you had easy access to multi-container 
>> ATOMICs
>> the packing would be unnecessary--would it not ?? That is in one 
>> ATOMIC event
>> you could update the pointer and the chunk of data independently and 
>> not NEED
>> to store them in a single container.
> 
> Well, actually, a pessimistic word based fetch-and-add (LOCK XADD) is 
> enough to increment the counter and load a pointer atomically all in one 
> shot, loopless. Why would I need to use multi atomics with a possible 
> loop to do that?

I try to avoid loops as for these as much as possible. Notice the 
difference between a weak and strong CAS in C++? Actually, I try to 
avoid CAS (strong or weak) whenever I can.