[concurrency-interest] Extended access methods for Atomics (and AQS)

Gregg Wonderly gergg at cox.net
Tue Apr 20 12:07:01 EDT 2010

gustav trede wrote:
> Hello ,
> So because of the fact that most people being "software engineers" are 
> evidently unsuitable for it and belongs in userland we should keep 
> ignoring the technical real world and make it hard or impossible for the 
> coders to do some actual good solutions ?.

Gustav, I appreciate this perspective, and I'm all for allow developers to 
maximize use of hardware.  The issue for me, is that I started using Java in 
1996 as my sole language of development, because I didn't want to have to mess 
around with verbose and problematic memory management.

The availability of simple "synchronized" made it very easy to manage 
synchronization between a handful of threads in a uni-processor environment.

As hardware has reached a standstill on clock speeds, we of course now have 
multi-core, hyper-threaded processors and multiples of those to boot.

So, now, we have contention for resources as a much more important performance 
issue, because you can't just crank up the clock speed.  Most things that you 
can do end up being less time consuming (sometimes by a big margin) than the 
time through a "lock", so threads eventually pile up in a line behind locks and 
we get much more interested in lock-free APIs.

All of this work to use fences to manage visibility and sometimes even 
synchronization, along with CAS, just feels like the wrong solution path to me.

It exposes hardware issues and encourages locks as a solution, both of which 
help make software much less portable and much more fragile over the longer life 
of the software.

Being a great software engineer and doing awesome things with software is a 
great achievement.  But, we are all mortal.  In the end, I think its much 
smarter to think about how we can keep software simple (and I don't just mean 
easy for ignorant people to write), so that success is easier.

In the end, we might have to just deal with the fencing directly.  But, I am not 
sure that there is really a great deal to be gained from that.  Instead, we 
might be better served to create classes with focused support for a particular 
problem which might use the "Unsafe" operations, but provide a "monitor" like 
function around that use which keeps software from decaying into "wrong".

Gregg Wonderly

More information about the Concurrency-interest mailing list