[concurrency-interest] Extended access methods for Atomics (and AQS)
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".
More information about the Concurrency-interest