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

Cliff Click cliffc at azulsystems.com
Thu May 18 11:43:46 EDT 2006

Better yes, but I'm looking for a cheapo solution I can tell customers 
to slap into their code.
Thread-local counters work where the ratio of increments-to-reads is 
real high, but not if reads are common.  That distinction requires me to 
know something about the application, i.e., it's not a no-brainer 
drop-in solution.

In one case I can say "use this standard API which you can read about in 
Sun's online javadoc's and even exists in 1.4.2 (sun.misc.atomic)" 
versus "if you aren't reading the counter alot, download this code from 
Azul and use it instead and also it requires 5.0".

It would help if a very-high-performance counter class made it into the 
JRE, so we can start moving people towards a portably-performant solution.


Bart Jacobs wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cliffc.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
Url : /pipermail/attachments/20060518/d6de84dd/cliffc.vcf

More information about the Concurrency-interest mailing list