C++0x: const/volatile blocks.
Davide Bolcioni
perusing introductory material on memory synchronization, I noticed
that the concept of 'memory barrier' instructions does not seem covered
in C++ (beyond library functions and asm, if it can be made to work).
Hence the following:
{
// this is a ordinary C++ or even C block ...
}
const {
// this is in a 'const block' ...
}
volatile {
// this is in a 'volatile block' ...
}
const volatile {
// this is a 'const volatile block' ...
}
As far as syntax is concerned, it is possible that the above should be
refined from e.g. 'const block' to 'const block statement', to avoid
clashing with const methods of a class. On the other hand, see below:
it might introduce the concept of 'pure' functions.
Within a const block, all variables except those declared in the block
itself are effectively const. It might prove useful to add some syntax
involving 'mutable' to e.g. declare a reference to a variable you intend
to modify, or it might not. Invocation of free functions results in a
compile time error, unless the language is extended to allow 'const' on
a free function with the semantics of 'const block', yielding a 'pure'
function; method invocations follow the usual overload rules.
A volatile block is like an ordinary block, but the compiler must ensure
that all visible effects of its execution are complete and visible to
other entities (processors, threads, nodes ... add what you wish C++0x
to include) when the block closes. This might include a memory write
barrier at the end, for example, but might also affect stuff such as
common subexpression evaluation.
A const volatile block, as you might expect, would include a memory read
barrier at start, if any.
While thinking this up, I found the D language which has a 'volatile'
statement, which tracks the notion of 'barrier instruction' more
closely, but I thought that a block would mesh better with RAII and
exception handling.
I wonder if the above would prove advantageous for optimization.
Best Regards,
Davide Bolcioni
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Michiel Salters
> Greetings,
> perusing introductory material on memory synchronization, I noticed
> that the concept of 'memory barrier' instructions does not seem covered
> in C++ (beyond library functions and asm, if it can be made to work).
> Hence the following:
> As far as syntax is concerned, it is possible that the above should be
> refined from e.g. 'const block' to 'const block statement', to avoid
> clashing with const methods of a class. On the other hand, see below:
> it might introduce the concept of 'pure' functions.
>
[snip]
> A volatile block is like an ordinary block, but the compiler must ensure
> that all visible effects of its execution are complete and visible to
> other entities (processors, threads, nodes ... add what you wish C++0x
> to include) when the block closes. This might include a memory write
> barrier at the end, for example, but might also affect stuff such as
> common subexpression evaluation.
In theory, we already have this. At any sequence point, all pending
actions must complete. However, since threads aren't in the standard
and memory
barriers aren't needed for single-threaded programs, compilers usually
(AFAIK, never) don't emit them.
Regards,
--
Michiel Salters
Andrei Alexandrescu
news:cefd6cde.03081...@posting.google.com...
In practice, sequence points will never work for inserting sequence points
automagically. If not explicitly told which functions are multithreaded,
the compiler would have to dramatically pessimize the code.
Threading primitives must be in the language. Although they could use the
existing syntax and appear as regular function calls or object definitions,
they must provide guarantees beyond what the standard specifies today.
Andrei
Davide Bolcioni
>>that the concept of 'memory barrier' instructions does not seem covered
>>in C++ (beyond library functions and asm, if it can be made to work).
>>A volatile block is like an ordinary block, but the compiler must ensure
>>that all visible effects of its execution are complete and visible to
>>other entities (processors, threads, nodes ... add what you wish C++0x
>>to include) when the block closes. This might include a memory write
>>barrier at the end, for example, but might also affect stuff such as
>>common subexpression evaluation.
> In theory, we already have this. At any sequence point, all pending
> actions must complete. However, since threads aren't in the standard
> and memory
> barriers aren't needed for single-threaded programs, compilers usually
> (AFAIK, never) don't emit them.
Yes and no. I am just starting to look into the matter, but requiring
the compiler to insert a memory barrier instruction at every sequence
point would result in too many memory barrier instructions, it seems to
me, and most of them would be wasted.
As long as C++ ignores threads, I agree there is no need to worry about
memory barriers and such. The purpose of the original proposal was to
allow the programmer to tell the compiler where he wants the barriers,
should the need arise. To preserve the semantics of current code, it
might prove necessary to emit barriers at sequence points - but the
proposed syntax would allow programmers to easily remove them from the
more troublesome spots (observed through profiling).
The 'const' block might be too weird, although it would have helped me
to refactor access to globals in a couple of instances.
Davide Bolcioni
--
There is no place like /home.
Andrei Alexandrescu
message news:bhscqh$2l2d9$1...@ID-14036.news.uni-berlin.de...
> In practice, sequence points will never work for inserting sequence points
> automagically.
Duh. I meant:
In practice, sequence points will never work for inserting memory barriers
automagically.
Alexander Terekhov
Davide Bolcioni wrote:
[...]
> As long as C++ ignores threads, I agree there is no need to worry about
> memory barriers and such. The purpose of the original proposal was to
> allow the programmer to tell the compiler where he wants the barriers,
See the usage 'msync' stuff in 'atomic<>' below.
http://www.terekhov.de/pthread_refcount_t/experimental/refcount.cpp
A sort of 'some wording' (on hoist and sink stuff) can be found here:
http://groups.google.com/groups?threadm=3EF2F960.301E9C99%40web.de
(Subject: Re: newbie question)
regards,
alexander.
P.S. http://google.com/groups?threadm=3EBF5B97.A501D252%40web.de
(Subject: Re: The Inventor of Portable DCI-aka-DCL (using TSD)...)