Re: Threading issue in next standard
wkaras@yahoo.com wrote:
kanze wrote:
kuyper@wizard.net wrote:
Jiang wrote:
I do not think Bjarne Stroustrup will change the language
a lot, since he said many times that library extensions
will be preferred to language extensions.
It's not Stroustrup's language anymore; it's the standards
committee which will decide whether and how the language
is changed. I'm sure he has opinions on the matter, and
they're likely to be given considerable weight by the
committee. However, since the language was standardized,
all that Stroustrup can change by his own decisions are
his own implementation of C++, not the official C++
language itself.
I think that there is a general consensus in the C++
community, and in the committee, that all other things being
equal, a library solution is preferable. I think that there
is also a very large consensus as to the need to support
threading, and a general recognition that this requires
something in the language.
I would hope that alot of brownie points would be awarded to
any proposed standard for which a portable open source
implementation as a layer on top of POSIX threads existed.
Existing practice is certainly desirable. (Except, of course,
when the effect of the existing practice was to show that it was
a bad idea:-).) The problem is that a code base isn't a
standard; you still have to specify what it does, and in the
standard, you cannot specify something as "whatever the
underlying OS happens to give you." (To start with, in order to
do this, you'd have to specify the mapping to the underlying OS.
All underlying OS's.) If nothing else, you've got to say that
the compiler cannot move code around something like:
std::scoped_lock( someMutex ) ;
(Posix guarantees it for C, and all of the Posix-compatible C++
compilers extend the guarantee for C++---although this wasn't
always true. Boost guarantees it for a Posix platform, because
you more or less know the implementation. Formulating it in
standard'ese, on the other hand, is less simple.)
Beyond that, it's important to realize that different people use
multithreading for different reasons. For what I do, a few
modifications in Boost.threads would do the trick. On the other
hand, I know of more than a few people who need to be able to
propagage an exception (of unknown type, but I think it would be
acceptable to limit it to types derived from std::exception)
across a join---this is impossible with Boost as it currently
stands (and without the limitation to std::exception, probably
impossible without explicit compiler support). And people using
threads to parallize numeric calculations, and such things, need
low lever, non-locking primitives: things like CAS or
atomic_incr.
I would also suggest adding (in std namespace) the "pseudo"
function template:
template <typename T>
void observe(const T &x) { ... }
If observe is called on an object x, then for every instance i
(directly or indirectly) within x, i of a primative type:
1. An observable write to i will fall between
the sequence point following a (value changing)
nominal write to i and the sequence point following
the observe(x) call.
2. An observable read of i will fall between
the s.p. following the observe(x) call and the
s.p. following a nominal read of i.
I think it's a bit more complicated than that. Observable by
whom? Under what conditions?
An important consideration is being able to the guarantee order
some set of writes becomes visible to other threads. But it's
part of the larger problem of the memory model in general.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]