Re: Musing about arcane (?) topics...

Okay, I see that the C++ example is actually trying to use two separate items that really need to be used together. This is a case for DWCAS. 

How do we have that problem in Lisp? You shouldn’t start looking at CAR and CDR contents until you have a lock on the list head. Only then can you rely on CAR and CDR contents.

The C++ example has optimistically (and incorrectly) looked deeper into the list before holding a lock on the list.



> On Jun 24, 2026, at 11:43, David McClain <[email protected]> wrote:
> 
> … and to expect even more, you would have to agree to perform only Functionally Pure coding, as visible by the rest of the world. 
> Internally, among local lexical bindings you can be as imperative as you like. 
> 
> As far as I can tell, it is impossible to enforce FPL conventions in Common Lisp. Just as it seems impossible to encode Copy On Write in Common Lisp.
> 
> 
>> On Jun 24, 2026, at 11:40, David McClain <[email protected]> wrote:
>> 
>> Oh yes, I absolutely agree with you and the article. (And I was considering only allocation problems.) 
>> 
>> But the Wikipedia example, I would contend, isn’t strictly an ABA problem. No history gets erased in this example.
>> 
>> You have in hand, the pointer to the head of the list. That hasn’t changed, despite its content being changed. Why should that be a problem? 
>> 
>> You aren’t still pointing at the old list linkages, just at the list head. Whatever changed along the spine of the list is visible to you as you make your modifications.
>> 
>> So, while technically, the absolute contents of the list may have changed, that shouldn’t be a problem for you once you get a lock on the object. You are locking access via the list head, and nothing more.
>> 
>> 
>>> On Jun 24, 2026, at 10:52, Martin Simmons <[email protected]> wrote:
>>> 
>>> Are you only considering ABA problems that involve allocation?  The lock-free
>>> stack example in https://en.wikipedia.org/wiki/ABA_problem could happen in
>>> Lisp.
>>> 
>>> -- 
>>> Martin Simmons
>>> LispWorks Ltd
>>> http://www.lispworks.com/
>>> 
>>> 
>>> 
>>>>>>>> On Wed, 24 Jun 2026 03:46:38 -0700, David McClain (as dbm at refined-audiometrics dot com) said:
>>>> 
>>>> Even more fundamental result: 
>>>> 
>>>> ABA problems *cannot* happen in Common Lisp proper (excluding FLI), nor in any other “Memory Safe” system. 
>>>> 
>>>> Storage for A (the old value) being held for use in a CAS operation, cannot be discarded by the GC and reused by an MRU allocator to produce a C object with Addr(C) = Addr(A).
>>>> 
>>>> An ABA problem arises when ABA could become ABC, with Addr(C) = Addr(A), just prior to the CAS operation. The CAS will succeed and produce ABX, where X = the locking value, thereby discarding C, and hence producing an “ABA Problem”. When ABX later gets updated to ABA′. The A′ will have been produced using stale information, A, and history, in C, will have been discarded.
>>>> 
>>>> There is no need to mandate immutability of data to avoid ABA problems in Lisp. They simply cannot ever happen.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Lisp Hug - the mailing list for LispWorks users
>>>> [email protected]
>>>> http://www.lispworks.com/support/lisp-hug.html
>>>> 
>>> 
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> [email protected]
>>> http://www.lispworks.com/support/lisp-hug.html
>> 
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html