Re: C++ Threads, what's the status quo?
"Zeljko Vrba" <zvrba.nospam@gampen.ifi.uio.no> wrote in message
news:slrneqh4ik.eo4.zvrba@gampen.ifi.uio.no...
The compiler needs to provide only two mechanisms:
1. A mechanism that lets the programmer specify that a sequence of
statements
shall be executed in the exact order in which these statements have been
specified. Ambiguities such as f(g(), h()) shall be flagged as error
and the programmer shall be forced to use intermediate variables.
2. A mechanism to specify that an access to a variable shall be atomic.
Thus, if a global variable x is to be used from two threads in
expression
like x += b; then it would have to be declared like something as
"atomic int x;".
(Some of the concepts being discussed are way out of my league. That said...
;))
Volatile<int> x;
Is your 'atomic' keyword too high level in that it's pushing into the
compiler level what can be accomplished at the programming level, namely
using synchronization primitives or instructions to wrap around variables?
Would 'atomic' be just a convenience and high performance thing to use in
alternative to something like Volatile<T> or direct inline wrapping with
locks? Are you saying that your 'atomic' keyword would allow getting rid of
all the synchronization issues and therefor primitives everywhere all the
time? Enquiring mind wants to know.
If the target architecture doesn't have an atomic
RMW instruction, this shall be an error. Assumptions for the correct
execution of the program (availability of appropriate atomic
instructions)
are violated, therefore the program has to be rewritten. Much better
than declaring the program as having UB.
Once these two mechanisms are in place, everything else can be provided by
a library.
I guess the question becomes: what is "everything else" and what did
'atomic' do away with and what is still needed?
Questions like "when is *x += 3; commited to memory" should
_not_ be addressed by the standard. If a memory barrier is needed, it can
be provided as a library function, and the code rewritten such as
volatile { *x += 3; barrier(); }
The point is that it is the *programmer's* responsibility to decide
whether
the barrier is neccessary, not the compiler's.
John
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]