Re: Threading in new C++ standard
On 19 avr, 20:03, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 19, 9:25 am, James Kanze <james.ka...@gmail.com> wrote:
The main issue isn't the library interface (although that is
important too). The main issue involves language rules: when
must a compiler ensure that a write is visible in other threads,
for example.
It is a good example. The visibility is quite straightforward
issue in any decent concurrent programming language: At the
end of the critical region a write that happened inside the
critical region is visible to the other threads.
Which is a language issue.
However, if the language is missing any language level means
to define a critical region, that is a problem.
Why?
It is typically the case when a language offers library level
means for concurrency.
Posix does it for C, without any real problems. It means that
language issues and the library are somewhat mixed, but there's
nothing new there.
In C++ it could have been solved with a single keyword:
`shared'. A shared class is basically a monitor (note that
originally the monitor was introduced as a shared class).
Here is an example:
shared class A {
int x;
public:
int s(const int n) {const int t = x; x = n; return t;}
};
The `x' is a critical resource which can be accessed inside a
critical region only.
Which covers about 10% of the reasonable uses. I rather prefer
the way it is being handled, where I have more options when I'm
building my higher level abstractions.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34