Re: Address space limits

Terje Mathisen wrote:

MitchAlsup1 wrote:

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?

 Postulate that you have a 64-bit pointer and a 8-bit chunk 72-total bits.
Further postulate that you need to update both in a single non-blocking ATOMIC event. ...

"Any programming problem can be solved with an additional layer of indirection", so in this case you create a handle to that 72-bit item, and require all access to go via the handle?

I am not trying to add an additional layer of indirection, I am trying (unsuccessfully it appears) to get Chris to think outside of the one
container ATOMIC box.

The addendum to the rule above is of course ", except the problem of too many layers of indirections". :-)

Terje