[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