[concurrency-interest] AtomicReference weakCompareAndSet "Mayfail spuriously"?

Cliff Click cliffc at acm.org
Thu May 18 02:00:44 EDT 2006


My use-case for AtomicInteger NOT forcing a happens-before is in 
high-performance perf-counters.  Since it's a perf-counter I've no need 
of a happens-before; but I can't tolerate the very high level of 
count-dropping that happens if I don't use a CAS.

In my case I've got 380 CPUs busy incrementing a counter; the counter 
goes up about 790,000 increments/sec (one increment per piece of 'real' 
work).  If I use a lock, I'm limited to about 50 CPUs and 60,000 
ops/sec.  If I use a strong CAS (CAS+fence) I get ~400,000 ops/sec.  If 
I use a CAS-no-fence I get 790,000 ops/sec.  That extra fence really 
costs!  This is admittedly an extreme case, but it's going to be less 
extreme going forward: next year we'll have double the CPU count.

For AtomicRef's I agree with Bill's statement: for ease of correct 
coding we should just require the happens-before.

The other option worth mentioning is just to define all variations, 
which can be trivially implemented by using the strong version, but 
would allow experts some lea-way on more interesting hardware.

Cliff


Bill Pugh wrote:

>
> On May 17, 2006, at 4:43 AM, Doug Lea wrote:
>
>> Bob Lee wrote:
>>
>>> On 5/15/06, Doug Lea <dl at cs.oswego.edu> wrote:
>>>
>>>> Yes, this is fine; it is a good example where either the plain or
>>>> the weak form would work just as well, so you might as well use
>>>> the weak form.
>>>
>>> Can you please provide an example of when you'd use one or the other?
>>
>>
>> Thanks to Bill Pugh for reminding me about a second difference
>> between weakCompareAndSet vs plain compareAndSet, that normally
>> goes hand-in-hand with the main difference of failure being
>> uninformative:
>>
>> A plain compareAndSet has volatile-write memory model semantics,  
>> while a
>> weakCompareAndSet has non-volatile-write memory model semantics.
>
> ]
>
> I would explain this differently (actually, the JMM requires that it  
> be explained differently):
>
> weakCompareAndSet has volatile semantics, _except_ that it doesn't  
> create any happens-before
> edges.
>
> Thus, using weakCompareAndSet is ideal for things such as performance  
> counters,
> unique identifiers and reference counting.
>
> However, what about AtomicReference? If you actually try to pass  
> references between threads,
> you need to establish a happens-before relationship between the two  
> threads, so that the contents of
> the object are communicated as well.
>
> So, here is the question we should discuss:
>
> **********
>
> Should weakCompareAndSet on an AtomicReference create happens before  
> edges (just as
> compareAndSwap does)?
>
> **********
>
> For AtomicInteger, and similar classes, there isn't a question. Just  
> for AtomicReference classes.
>
> I talked with Doug, and we agreed that we didn't have enough use  
> cases to really decide.
>
> The only possible use for a weakCompareAndSet on a reference where  
> you don't need a happens-before
> edge is if you can prove that a happens-before edge is created by  
> some other mechanism.
>
> So, if weakCompareAndSet does not establish a happens-before  
> ordering, then a few people (i.e, just Doug)
> might be able to effectively use it to superoptimize some code.  
> However, without the happens-before ordering,
> some potential use cases are invalid, and many people trying to use  
> it will create a data race.
>
> Thoughts?
>
>     Bill
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cliffc.vcf
Type: text/x-vcard
Size: 136 bytes
Desc: not available
Url : /pipermail/attachments/20060518/8163d2f0/cliffc.vcf


More information about the Concurrency-interest mailing list