Possible language changes

[Maged Michael]

I am not sure how successful compilers can be in removing unnecessary 
barriers. Will they be able to generate code with no more barriers than 
ideal assembly.

About DCL, I quote the following from the JSR 133 FAQ:
http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html#dcl

"However, for fans of double-checked locking (and we really hope there are 
none left), the news is still not good. The whole point of double-checked 
locking was to avoid the performance overhead of synchronization. Not only 
has brief synchronization gotten a LOT less expensive since the Java 1.0 
days, but under the new memory model, the performance cost of using 
volatile goes up, almost to the level of the cost of synchronization. So 
there's still no good reason to use double-checked-locking."

I don't know if this is an accurate assessment of the cost of volatile or 
not after taking compiler optimizations (removing barriers) into account. 
In any case, my opinion is that C++ should allow at least simple things 
like DCL to be as efficient as being written in assembly. Do we agree on 
that?

Maged





Doug Lea <dl at cs.oswego.edu> 
03/02/2005 07:16 AM

To
Maged Michael/Watson/IBM at IBMUS
cc
"Boehm, Hans" <hans.boehm at hp.com>, Andrei Alexandrescu 
<andrei at metalanguage.com>, asharji at plg.uwaterloo.ca, Ben Hutchings 
<ben at decadentplace.org.uk>, Doug Lea <dl at altair.cs.oswego.edu>, Jim Rogers 
<jimmaureenrogers at att.net>, Kevlin Henney <kevlin at curbralan.com>, Bill 
Pugh <pugh at cs.umd.edu>, Richard Bilson <rcbilson at uwaterloo.ca>, "Douglas 
C. Schmidt" <schmidt at dre.vanderbilt.edu>
Subject
Re: Possible language changes






> My concerns are: (1) Fence instructions are expensive, roughly 100 
cycles, =
> 
> (2) Full acquire/release semantics are not needed in most accesses to=20
> volatile variables in many useful algorithms. I'll try to give some=20
> examples below. (3) Once the language gives a strong guarantee, it is=20
> almost impossible to take it back. So, I prefer giving minimal 
guarantees.
> 
> My preference is to separate memory ordering from volatility and=20
> atomicity.
> 

My initial thoughts (in the original proposal) were to give "volatile"
strong semantics, but to provide methods in the atomicX classes that
provide more flexible barriers. I still think this is a good idea.
(It's an extension of what we did in Java.) People developing carefully
crafted nonblocking algorithms would have to use atomics rather than
volatile, but there is no penalty for doing so
except for more awkward syntax . These classes have no virtual methods
and only hold a single (int, long, pointer), so there is no space
or time overhead.

One advantage is that people doing ordinary things like
double-checked locking can make their code work simply by declaring
fields volatile, without requiring a deep knowledge of ordering and
barriers (which few programmers know much about). Also, as in Java,
compilers can optimize away some of these barriers. (See the table
near the end of my http://gee.cs.oswego.edu/dl/jmm/cookbook.html --
The Sun (and I think JRockit) server JVMs actually do most of these
on x86 and sparc.)

But if you are smarter than the compiler and need manual control, you
can use atomic classes.

Can you live with this?

If not, can you think of a reasonable alternative?

If so, there are still some details to be worked out on the form
and semanitcs of some of the methods on atomics, but it seems
straightforward. (For example, should there be a method that performs
a not-necessarily-atomic read on an atomic?)

-Doug







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadbolt.decadentplace.org.uk/pipermail/cpp-threads/attachments/20050302/d9191e7b/attachment.htm