From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrew Tropin Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add atomic-box-update! function to (ice-9 atomic) Date: Thu, 22 Jun 2023 13:02:55 +0400 Message-ID: <871qi3q37k.fsf@trop.in> References: <874jn0pxtz.fsf@trop.in> <47D08644-D34F-43C2-9B0C-24A790F3CEA7@abou-samra.fr> <87ttv01711.fsf@trop.in> <4c24e86e-2dcb-4d41-89c4-67814b6ef4f1@app.fastmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6067"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org, Andy Wingo To: Philip McGrath , Jean Abou Samra Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Thu Jun 22 11:03:35 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qCGE3-0001Ju-Bn for guile-devel@m.gmane-mx.org; Thu, 22 Jun 2023 11:03:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCGDd-0000ql-Te; Thu, 22 Jun 2023 05:03:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCGDb-0000oi-Nu for guile-devel@gnu.org; Thu, 22 Jun 2023 05:03:07 -0400 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCGDZ-0006xj-NG for guile-devel@gnu.org; Thu, 22 Jun 2023 05:03:07 -0400 X-GND-Sasl: andrew@trop.in DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop.in; s=gm1; t=1687424582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hZbScQ1uLMwQbVrwp9E8LvkME8H3gXARsfu5QUqjwGQ=; b=SnVbofk6jyOlVQZB6GkLyEXZKnAWp0BkfvBtV/UuTBWTVJe4cJQw73bJDWqDwCfdDHhy/Q h8veh2e0Qt3jyhOJhGxUt5GvYz2BZud+wKfH1PyslhhD6sVwRXPksFib+0zwwS+8ufOVF9 fqDi7FyaYF0ru6ul/yLqR7Jn90+gJNRJZSXFvsNeHlIOwFkc7CM7+uG+yfWbVU20S7umSK Bim5k/IHAp0c6qkcIAJ80z2vqC1iECoozICALyPDigZeQCH1Yjp4B0gZx9YymNpqxoD2k6 R/6iIX263AuQVFtU+6eMJrEe4++JTk5QBHd3cKstxrYoE8J/XYDpCflcJVilmQ== X-GND-Sasl: andrew@trop.in X-GND-Sasl: andrew@trop.in X-GND-Sasl: andrew@trop.in Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 35EC224001A; Thu, 22 Jun 2023 09:03:00 +0000 (UTC) In-Reply-To: <4c24e86e-2dcb-4d41-89c4-67814b6ef4f1@app.fastmail.com> Received-SPF: pass client-ip=217.70.183.193; envelope-from=andrew@trop.in; helo=relay1-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21874 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 =C3=A0 18:46, Andrew Tropin a =C3=A9c= rit : >>>>=20 >>>> 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)) =3D=3D> _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 =3D 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 =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmSUDj8ACgkQIgjSCVjB 3rBTeQ//TG4W3/FHpFAsmszbRrVGFSGFFVTicLzhVxtJX3zr4GYdh9hWEsupq5Cr +Z3r3+fRa28Fgy0UV1o8t98+4+xmUmGzpBt/d6O4Hpz1iZtdaEVArWsB76CTEIF1 +ax+P+G2DO6srRhSgL1wyb92Bmvv9t6G7D4nDCVAm4zNBDke/9HAqncaE2aJPXXJ J7BYZb6Rzw0ysr6SXnonToJRpAmsRkDrwxFiDOcGVVa2qxh9mP+dbCHK0nnRvo4B ezfn0a0xprvwGhN8bi3r/kZJph9YzON7O9jSXJsiyQHezO1iXBuZAUCv+VD1HpWx kg10YeyZ/4MwIlKcOxWoqYlhZLDM/xELYRkJmtbGc0F5wr5EfR3BdJpTWSZkMCxK JkREKMw2kiD3s6uX2OJGp2OzX40oGM5w+7OapczqFq3UlAgYs3XFPRCtefvO6HqS LLJdsaWBM8ps5aBBjY8gIMPzQOpkDVkjqdIJwA3SUoFSz0AhVJJIQZOs0sC2vwNw J6Tl6Sz8e5StWO64ZHBkl8Zg5/1nki+qQZoqyfsSSKkHO2LCgCXXi52qBx3o6MDM GshLG9y0CzjyCeNPrdjDpJekZczFHvuiM2rO59HqcW+Kv8qg4W285C4KKWTNvzyV /ZlzkgggPlGEyyW4mEEx0jgLZ4iAprNOz0lj04Danwp6R2b8HkE= =gtzx -----END PGP SIGNATURE----- --=-=-=--