Re: [PATCH] Add atomic-box-update! function to (ice-9 atomic)

[Andrew Tropin]

On 2023-06-22 01:21, Philip McGrath wrote:

> On Wed, Jun 21, 2023, at 11:59 PM, Andrew Tropin wrote:
>> On 2023-06-21 18:54, Jean Abou Samra wrote:
>>
>>>> Le 21 juin 2023 à 18:46, Andrew Tropin <andrew@trop.in> a écrit :
>>>> 
>>>> Make sense, but it's hard for me to say something valuable on this
>>>> topic.  Usually, I don't use eq? and don't have enough knowledge of its
>>>> internals.
>>>
>>>
>>> *Currently*, it just checks whether the two C-level SCM values are the
>>> same bitwise, so even implicit copies of fixnums will remain eq?. In
>>> theory, Guile could make copies of bignums. I am not aware of it doing
>>> so.
>>>
>>> However, all that is guaranteed is that (eq? a a) when a is a
>>> non-immediate (pair, string, vector, hashtable, etc) or one of a few
>>> constants like booleans, the empty list and *unspecified*. Notably, it
>>> isn't guaranteed for numbers or characters.
>>>
>> [...]  I'm
>> almost sure that we need eq? here as we need to make sure that the value
>> previously stored and returned atomic-box-compare-and-swap! is the same
>> object in memory, however this example from manual is indeed confusing:
>>
>> --8<---------------cut here---------------start------------->8---
>>  (let ((n (+ 2 3)))
>>        (eq? n n))                           ==>  _unspecified_
>> --8<---------------cut here---------------end--------------->8---
>>
>> So maybe you are right and it's better to use eqv? here.
>>
>
> The problem with eqv? is that it doesn't correspond well to
> machine-level atomic compare-and-set instructions, so using it would
> defeat the purpose of lightweight atomic boxes.
>
> R6RS specifies that "the behavior of eq? on number objects and
> characters is implementation-dependent, but it always returns either
> #t or #f, and returns #t only when eqv? would also return #t." [1] I
> think the right thing to do here is for Guile to provide more
> guarantees about its implementation of eq?.
>
> Guaranteeing that fixnums are eq? when they are = would be
> particularly reasonable and extremely unlikely to cause constrain any
> future port of Guile: the whole point of fixnums is to support
> efficient machine operations like this. I also think most Schemers
> would be quite surprised if (lambda (x) (eq? x x)) ever returned
> #f. More broadly, *The Scheme Programming Language* says at the
> beginning of its documentation for eq? that, "In most Scheme systems,
> two objects are considered identical if they are represented
> internally by the same pointer value and distinct (not identical) if
> they are represented internally by different pointer values, although
> other criteria, such as time-stamping, are possible."

Thank you very much for in-depth explanation!

>
> In any case, the current documentation for
> atomic-box-compare-and-swap! is clear that the comparison is eq?: it
> just means that, when the behavior of eq? is unreliable, so is the
> behavior of atomic-box-compare-and-swap!.

Good.  Than implementation of atomic-box-update! looks correct to me.
Any thoughts on including it in (ice-9 atomic)?

>
> Tangentially, does atomic-box-compare-and-swap! handle spurious
> failures on architectures like ARM, or does it expose machine
> semantics to the programmer? Maybe that's covered by details of the
> C11 memory model, but I don't think "sequential consistency" alone is
> enough to answer the question.
>
> -Philip
>
> [1]: https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.5
> [2]: https://scheme.com/tspl4/objects.html#./objects:s10

-- 
Best regards,
Andrew Tropin

signature.asc
Description: PGP signature