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

Bart Jacobs bart.jacobs at cs.kuleuven.ac.be
Thu May 18 07:30:04 EDT 2006


Wouldn't it be better to increase the granularity of your counter? Use 
thread-local counters and increment the shared counter per thousand 
pieces of real work?

Note: it's probably best to use some app-specific mechanism for 
thread-local counters, since ThreadLocal may have high overhead.

Thanks,-
Bart

Cliff Click wrote:
> 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
>>
>>
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



More information about the Concurrency-interest mailing list