Re: Threading in new C++ standard
On Apr 17, 9:25 pm, schm...@tango.dre.vanderbilt.edu (Douglas C.
Schmidt) wrote:
Or no model; like most other libraries, it's just a wrapper for
whatever the implementation gives you.
That's not entirely the case, e.g., the ACE_Thread_Manager is
more than just a wrapper over the underlying implementation.
Naturally, if the OS doesn't support threads at all it's hard
for a library-based implementation to do much about this..
What I meant is that you don't really define when external
synchronization is needed, and when it isn't. Under Posix,
external synchronization is needed when Posix says it's needed,
and under Windows, when Windows says it's needed.
This is the aspect which really has to be treated at the
language level: what does a "sequence point" mean in a
multithreaded environment? There are also library aspects: when
do I need external synchronization when using library components
in two different threads.
Seriously, what I was referring to was the fact that you
have (or had, at least) a Thread class, from which the user
had to derive.
I assume you're referring to ACE_Task here? It implements an
Active Object model that's similar to Java's Thread class + a
synchronized message queue.
And Java's Thread class is an example of a poorly designed
interface for threading. At least today; it was pretty much
standard practice when it appeared, but we've learned a lot
since then. And are still learning: I'm not sure that even
today, threading technology is mature enough to be technically
ready for standardization. (But politically, we don't have a
choice. If the next version of the C++ standard doesn't address
threading, the language is probably dead.)
This was, of course, the accepted practice when ACE first
appeared, but we've found better solutions since then.
Can you please point to some descriptions of these solutions?
Boost offers parts of them. The whole concept of functional
objects changes the situation considerably.
IMHO, too, what I've learned from practical experience is that
joinable threads and detached threads are two very different
beasts. For detached threads, the best solution I've found so
far is a template function, something more or less like:
template< typedef Function >
void
startDetachedThread(
Function f )
{
boost::thread( f ) ;
}
Fire and forget, in sum, with copy semantics handling all of the
memory management issues.
For joinable threads, you still want the thread class to take
the functional object as an argument (so that you're ensured
that it fully constructed before the thread starts). In Java,
for example, deriving from java.lang.Thread is a common source
of errors (which don't occur if you pass a Runnable to the
constructor of Thread). In C++, the issue is further
complicated by memory management issues, since there's no
garbage collection. (I don't think that they're necessarily
difficult issues, and I suspect that there are several
acceptable solutions. But they do have to be addressed.)
I'm not really too sure how ACE handles this; it's been a long
time since I last looked at it (and it may have evolved since
then).
I'm also not too sure how (or if) ACE handles propagation of an
exception accross a join. It's important that the standard
offer some sort of support for this as well. Although I don't
think it should be the default, and it doesn't bother me if it
requires some programming effort to get, it is currently
impossible to implement in Boost, and I suspect in any other
threading system (since it also requires some language support,
which isn't there at present).
There's also the problem, IIRC, that there is no real
distinction between detached threads and joinable threads.
It's not clear what you mean by this - can you please explain?
The ACE_Thread_Manager implements both detached and joinable
threads atop all the underlying operating systems, not just
POSIX pthreads.
But do you even need a thread manager for detachable threads.
Note that I'm talking here about the lowest level; the one which
must be in the standard. There's definitely place for more
elaborate (and less general) models at a higher level.
With regards to standardization, what ACE has going for it, of
course, is the fact that it probably has more users than all
other systems combined, and we have a lot of concrete experience
with it. What it has going against it is its age (it doesn't
take into account all of the changes in programming style in the
last years), and the fact that no one in the committee is
championing it. (The Boost group are very active in
standardization. You and others working on ACE don't seem to be
so.)
What all existing libraries have going against them (IMHO) is
that the "existing practice" with regards to threads is that
most multi-threaded programs don't actually work, or won't if
the active thread changes at the wrong moment, of if they're
ported to a multi-processor system, or if any one of a number of
other things occur. From a technical point of view, this means
that it's probably too early to standardize threading this go
round. From a political point of view, however, I don't think
we have a choice.
--
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