[Bordeaux-threads-devel] compare-and-swap

[Josh Marchán]

Luís Oliveira recently published a blog post
(http://kvardek-du.kerno.org/2012/06/augmenting-bordeaux-threads-with-atomic.html)
iscussing the possibility of extending BT with atomic operations (like
compare-and-swap). He put together a very handy table about implementation
support for this operation, which gives the impression that it might indeed
be a good time to wrap this feature in a portable API.

I'm working on a library that happens to use compare-and-swap, and wrote
the following macro:

(defmacro compare-and-swap (place old-value new-value)
   #+sbcl
   (let ((old-val-var (gensym "OLD-VALUE-")))
     ` (let ((,old-val-var ,old-value))
         (eq ,old-val-var (sb-ext:compare-and-swap ,place ,old-val-var
         ,new-value))))
   #+ccl
   `(ccl::conditional-store ,place ,old-value ,new-value)
   #+lispworks
   `(system:compare-and-swap ,place ,old-value ,new-value)
   #+allegro
   `(excl:atomic-conditional-setf ,place ,new-value ,old-value)
   #-(or allegro lispworks ccl sbcl) `(error "Not supported."))

I've tested this in all the mentioned implementations. I'm considering
putting together a patch to add this macro to BT itself, and I'd like to
know if this would be wanted, if there's any issues with the API itself,
etc.

There are two big issues I see:

1. On CCL, conditional-store is an internal, unexported operation. It's
also pretty narrow in what it can handle, and even breaks in situations
such as typed struct slot access. rme was kind enough to create a ticket
for this on the Clozure CL tracker, so this issue may be resolved in the
(near?) future: http://trac.clozure.com/ccl/ticket/994

2. CAS support across implementations has a lot of 'but's associated with
it. The only thing that seems to be supported across the listed
implementations is svref and struct access. There's also weird behavior on
some implementations (notably SBCL) when it comes to accessing dynamic
variables (where it can only access the global binding, not the local
one). Is this acceptable? Should a patch include compile-time warnings or
errors when we detect (when possible) that CAS is being used on an
unsupported place? Should it be left up to users to use it in the right
case? Should it break for anything other than svref and structslot, which
are the only ones supported across the board?

--
Josh Marchán
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120720/24e34b8a/attachment.sig>