pre-LilleHammer mailing deadline

[Boehm, Hans]

I've been
spending a fair amount of time on the C atomic_ops package (a
new version should be out soon), which provides one possible design
point, though not for syntactic and mechanical issues, which
will be different for C++.

My usual assumption has been that when there is a choice between
A and B, and either A or B are a clear win in some cases, do both
A and B.

Thus on architectures like PA-RISC (I think SPARC V8 and earlier
is similar, as are probably some others) by default, the
package will tell you there is no CAS.  But you have the
option of requesting an emulation if that's essential to your
application.

Unfortunately, at least user-level emulation is ugly, especially
if you want some measure of asynch-signal-safety, which I think
the language standards don't address.

Things get messier if you want to try to expose double-width CAS.

Itanium and the Intel version of X86-64 use two different variants,
which seem to show through to the application layer.  You can't really
emulate either one with the other, though both work fine for all common
cases.

I'll add the following section:

\subsection{Atomic read-modify-write support}

As described in the earlier document, we plan to add library access to
the atomic read-modify-write operations provided by most modern
hardware.
The difficulty is that such operations are not implemented by all
hardware,
and even if they are implemented, operations such as {\it
compare\_and\_swap}
will be implemented for differently sized data on different hardware.
Software emulations of these are only partially satisfactory.

We are discussing to what extent we should rely on emulations here, as
opposed to directly exposing the hardware differences to the programmer.
(Hybrids will clearly also be considered.)

It would be useful to be aware of any hardware that is likely to
remain critical in the future, and provides a significantly different
set of
atomic update operations from the mainstream desktop or server
processors
that our group is familiar with.

Hans

> -----Original Message-----
> From: Ben Hutchings [mailto:ben at decadentplace.org.uk] 
> Sent: Sunday, March 06, 2005 3:45 PM
> To: Boehm, Hans
> Cc: Andrei Alexandrescu; Doug Lea; jimmaureenrogers at att.net; 
> Kevlin Henney; Bill Pugh; Maged Michael; 
> asharji at plg.uwaterloo.ca; Richard Bilson
> Subject: RE: pre-LilleHammer mailing deadline
> 
> 
> I am attaching a couple of patches.  The first has a bunch of 
> minor improvements (IMHO) to style and clarity and also fixes 
> the spacing after abbreviations.  The second is an attempt to 
> clarify the example of duplicate reads from memory, which I 
> thought was confusing due to the mixing of variable and 
> register names.
> 
> There is no mention of atomic operations other than as the 
> potential semantics of access to volatile objects.  If I'm 
> not very much mistaken, read-modify-write operations are 
> essential to most lock-free algorithms. Is there consensus 
> that these belong in the library?  In any case, is there not 
> a question, similar to that for atomicity of volatile access, 
> of whether they should be optional, given the variation in 
> native atomic operations between architectures?
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Theory and practice are closer in theory than in practice.
>                                 - John Levine, moderator of 
> comp.compilers
>