[cpp-threads] Failed compare-and-swap

Lawrence Crowl Lawrence at Crowl.org
Thu Aug 2 21:52:38 BST 2007


On 8/2/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> How about a "memory_order_unspecified", so that the failure_order
> would by default follow the success_order?

I don't much like introducing a non-ground value into the memory
order enumeration.  On the other hand,

> But it is also reasonably likely that the user would weaken success_order
> and want the same weakening of the failure order, right?  Also, I am
> concerned about the following:
>
>         x.compare_swap(&old, new, memory_order_relaxed);
>
> This would -not- be a relaxed operation under your proposal, but would
> instead be sequentially consistent on success and relaxed only on failure.
> I believe that a natural reading of the above would lead the reader to
> believe that the operation was relaxed on both success and failure.

Well, I don't think you would always want the same failure order
as success order except at the extremes of sequentially consistent
and relaxed.

> Also, I believe that it is more natural for the success case to come
> first in the argument list.

Yeah, but I was working on the assumption that you'd first want
to weaken the failure case, which requires that that parameter be
first.  Sigh.

I think I'd like to leave the current definition in place.  The primary
place you'd want them to be the same is for relaxed and sequentially
consistent, and the latter is covered by the defaults.

> > > In the event of failure, there is still value dependence on the load.
>
> Interesting -- where do I find the definition of "value dependence"?

I write too quickly at times.  From 1.10p7 of draft N2334

    An evaluation A that performs a release operation on an object M
    synchronizes with  an evaluation B that performs an acquire
    operation on M and reads either the value written by A or, if the
    following (in modification order) sequence of updates to M are
    atomic read-modify-write operations, a value written by one of
    these read-modify-write operations.

-- 
Lawrence Crowl



More information about the cpp-threads mailing list