[cpp-threads] A niggle on the atomic model (N2145)

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Apr 19 14:51:59 BST 2007


"Paul E. McKenney" <paulmck at linux.vnet.ibm.com> wrote:
>
> As I understand it, this will unconditionally fail.  The locations of a
> load_linked() and the corresponding store_conditional() must match, or the
> store_conditional() will fail.  In this case, the enclosing "if" statement
> guarantees mismatch, which in turn guarantees store_conditional() failure.

That is not my understanding, and would make it a most unhelpful
interface, but I will check when I get back.

> Even given an extended load_linked()/store_conditional() that did what you
> want, in most implementations, store_conditional() is subject to spurious
> failures due to interrupts, context switches, exceptions, and the like.

That is not the point.  Such uses will cause a delay, but not an
infinite one, unless there is a hard error.  The example above is
something that will NEVER complete (i.e. it will loop indefinitely).

> My take was that the point of the address-free requirement is that
> the data structure should itself either contain or identify any
> mutual-exclusion apparatus required to make accesses to the same object
> from different virtual addresses be atomic.  But I must defer to Lawrence
> and Hans on this.

How?  Virtually no operating system lets applications even find out
post-hoc what the virtual/physical translations are.  To do that
needs operating system support, of a form that has been strenuously
resisted for 4 decades.  How do you do it without that and without
a global barrier?


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679



More information about the cpp-threads mailing list