Re: Threading issue in next standard
Earl Purple wrote:
SuperKoko wrote:
I hope it'll be a library facility.
It can't be purely a library facility, and still be portable.
Even Posix makes requirements with regards to what the compilers
can do, and what user code is allowed to do. Language
requirements.
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.
Does a "library facility" mean a "standard" interface that is
written to wrap what is already there?
Well, I don't think anyone is proposing something that will
require modifying the OS. If a proposal cannot be implemented
under Unix and Windows, as they currently stand, then I don't
think it will fly.
In that case, your STL will probably come with a bunch of
pre-processors.
I'd rather see it implemented with a C++ runtime library
rather than simply a bunch of "wrapper" classes for pthreads
or whatever happens to be the standard C threading library on
the system.
I've mentionned Boost before. It's certainly being considered.
I can't image it being adopted "as is", without any changes, but
I can't imagine it being ignored, either.
I'm sure that many people would say that we already have
POSIX. So, why would we have to add anything else.
Because POSIX is a C interface and we don't want to have to
write our programs in C just beause they happen to compile. A
good C++ library would
- use RAII locks, preferably with move-semantics.
Would support RAII locks. You certainly don't want to impose
them; that comes down to Java's synchronize.
- exceptions if thread-creation fails rather than returning
error codes. No need to call "get_last_error()" or any
equivalent because the exception will hold the reason.
I think that will largely depend on what a thread actually is,
but all in all, I suspect that the error reporting mechanism
will be exceptions.
- use a class method for thread-creation, not a function
pointer.
Most likely, something along the lines of boost::function, I
would guess. The best of both worlds, so to speak. (Or a
refusal to committee to one paradigm.)
The only downside of course would be possibly having to drop
my own threading classes in favour of the new "standard" ones.
Actually it was fairly tricky to implement condition-variables
together with my Mutex locks because condition variables
silently modify the mutex state so I had to couple them in
with Mutex. At least I was able to get away with this using
only a forward declaration and awarding friendship.
Condition variables ARE tied in with Mutexes. In every
interface I've seen.
One can, of course, conceive of higher level structures, which
encapsulate a number of things; I've got a message queue that I
use a lot in my own code, for example. Given the time frame and
the available existing practice, I don't expect any such things
in the standard.
I'm just guessing here, and I could be way off, but I sort of
expect:
-- a very precise definition of the memory model in a
multi-threaded context,
-- a set of library components more or less similar to
boost::threads, and
-- probably, because there seem to be a couple of experts who
think important, and are willing to work on it, some lower
level synchronization primitives.
Whilst I would like the basic functionality to be a "language"
feature (i.e. not simply coded as a wrapper for the C library
that is already there) I would like to see a library with it.
For example, I have a very useful producer-consumer-queue
"collection" (uses std::deque), and there could possibly be
other synchronised collections.
I'd like such things too, but I think it's asking too much given
the time frame we have to work in.
What would possibly be good is to be able to have keywords
like "atomic" so you could put in your code. Maybe also a
keyword atomic_if thus:
atomic_if( ---x == 0 )
{
// block
}
which would guarantee atomic decrement with result checking.
There is a desire for some primitives along those lines, and
work is being done on them.
By the way, there is already one feature of
thread-synchronicity in the standard language - the keyword
"volatile". Outside of a multi-threaded environment I don't
know what purpose the keyword serves.
As it currently stands, it serves no purpose in a multithreaded
environment, and no purpose whatsoever as implemented in the
Sparc or PC Linux compilers I have access to. It's original
purpose (support for memory mapped IO), of course, doesn't
concern programs in user environments on such machines; it could
be relevant for code in the kernel, however, if the compilers
actually implemented what was needed.
Microsoft has "redefined" volatile for use in multi-threading,
and have proposed that definition as a modification to the
standard. I'm not sure what the opinion of the committee is on
it; if nothing else, their redefinition corresponds to a common
misconception concerning current practice. (On the other hand,
they don't seem to have implemented it in the compiler in Visual
Studios 2005.)
That's why I prefer programming in POSIX+C++ than in Ada or
any other language containing an intrinsic concurrent model.
The presence of having language features won't prevent you
from extending the library set by writing libraries of your
own.
When you think about it, all of STL and boost is no more than
extending what was already there in the language.
But you can't do threading in just the library. There are
language level issues that must be addresses, such as memory
synchronization.
--
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 ]