Re: Just take me out back and shoot me...

In a way, this is similar in effect, to the superfluous locking introduced by Claude, shown here in a snippet of its code for a shared FIFO Queue implementation:

(defstruct queue
  "A thread-safe FIFO queue supporting multiple readers and writers"
  (head nil)           ; Front of queue (for dequeue)
  (tail nil)           ; Back of queue (for enqueue) 
  (size 0)             ; Current number of elements
  (lock (make-lock "queue-lock"))           ; Mutex for thread safety
  (not-empty (make-condition-variable)))    ; Condition variable for blocking reads

(defun queue-empty-p (queue)
  "Check if queue is empty. Thread-safe."
  (with-lock-held ((queue-lock queue))
    (null (queue-head queue))))

(defun queue-size (queue)
  "Get current number of items in queue. Thread-safe."
  (with-lock-held ((queue-lock queue))
    (queue-size queue)))

In both instances, only one slot of the structure is being queried. It makes no difference whether or not you lock the structure before querying the slot. A lock would be needed only when you need a coherent reading from more than one slot.

So, Claude must have been trained on someone else’s code, and that person was just being overly cautious. ChatGPT must have seen examples of exponential backoff being used when contention arises in communication channels, and (its suggestion) Transactional Memory.

But now, for TM, I’m beginning to see that exponential backoff won’t be useful there for the same reason it isn’t useful for my Actors system. In a CAS race, exactly one thread will always win.

- DM

> On Aug 10, 2025, at 06:26, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> Okay… just ran into another AI “Red Herring”.  
> 
> ChatGPT suggested an “exponential backoff” algorithm in the retry of losing threads facing a CAS contention for safe mutation of Actor shared state.
> 
> Given parallel concurrent execution of an Actor body code by two or more CPU core threads, several may attempt a state mutation by way of BECOME. 
> 
> All message sends and state changes are deferred transactionally to the successful exit of the Actor body code. Ensuring that the state mutation is safe must be mediated by a CAS operation, under which only one thread will succeed. The other threads need to retry their Actor message delivery against the newly updated state.
> 
> GPT suggested an exponential backoff before the message delivery retries. But this is pointless in this case, unlike network message collisions, because exactly one of the threads will have succeeded in the state mutation. That thread will not be retrying anything - there is no contest between all the players. So there is no point to delaying the retries by the losing threads here.
> 
> In a communication channel, when two messages arrive at the same time, both messages must be retried, and so random exponential backoff is useful there.
> 
> So GPT has not hallucinated in this case. It is not asserting an opinion as a fact. But it is injecting a superfluous argument that ends up wasting the time of the human in this interaction, as the human must think about the offered answer before finding it useless. 
> 
> This is a subtle distraction that I have not seen discussed.
> 
> - DM
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html