Re: Threading issue in next standard
Jiang wrote:
SuperKoko wrote:
Jiang wrote:
Several days ago, James Kanze said that thread issues will be addressed
in next standard.
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/7900a13685a8b8c2/47b6d8f6ce67f963#47b6d8f6ce67f963
If this is true, I would like to know that:
1. How will the language and library overlap?
That is, threading will be purposed by library
extension (like boost.thread), or adding new
language constructs, such as keywords like
"synchronized"?
I hope it'll be a library facility.
Languages having builtin threading tend to impose a single very
particular mean to do multithreading and it's easy to reach the limits
of those models.
Maybe this is true. But if this "single very particular mean"
helps, then do we really need the freedom for threading?
For example, compared with
void foo()
{
scoped_lock(mutex); // OK, RAII used here
// access the resource...
}
, the following function bar
void synchronized bar()
{
// access the resource...
}
is much clean and well controlled in my mind.
Except that even in Java, I've almost never found a case where
the scope of a single function corresponded exactly to the scope
necessary for a lock; in fact, the coding guidelines where I was
working ended up banning synchronized functions.
Much of the time, a synchronized block was appropriate, and of
course, scoped_lock emulates this very well---I don't see
anything to make you want to prefer one over the other.
And of course, "much of the time" isn't always. There are cases
where you want or need a lock whose lifetime doesn't correspond
to that of a scope. If you have a synchronized block in the
language, you need a fairly complex control object (using
conditionals) to implement it. If you only have scoped_lock,
you need something like shared_ptr( new scoped_lock ). And if
the locking primitives are available outside of scoped_lock,
it's even easier.
Here programmers do not have to remember RAII,
well, if RAII is parts of the language. Compared
with lock/unlock, constructor/destructor is much
reliable, but why not make a futher step?
Because it is more constraining. And at the function level,
doesn't really work in practice.
The problem is, even we have a thread library, lots of
low level details must be handled by our programmers.
Library or language won't change that. Problems such as correct
memory synchronization exist, and we can't legislate them away.
To fight with the complexity of threading, we really need
necessary language level abstraction in my mind.
Higher level abstractions do help. But many of them are
application dependent. And I don't think that there is enough
time before the next version to standardize the few which
aren't---we'd have to make them publicly available somehow
(ideally in boost), and get people using them, so we get some
feedback.
--
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 ]