 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jiang
Guest
|
 Posted: Fri Aug 18, 2006 3:58 pm Post subject: Threading issue in next standard |
 |
|
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"?
2. Is it possible that in the recent future we
will have a C++ binding for threading? If not, why?
3. This is maybe a little bit off-topic, but it is said
that Bjarne Stroustrup has been working with
concurrent programming for at least 20 years,
for what reason he (together with committee
members) did not add threading to the language?
C++ predates POSIX? Lack of manpower? Or simply
the complicity?
For this question I traced into D&E, but without
any luck.
Any comments are welcome.
---
[ 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 ] |
|
| Back to top |
|
 |
SuperKoko
Guest
|
| Posted: Sat Aug 19, 2006 4:03 pm Post subject: Re: Threading issue in next standard |
|
|
Jiang wrote:
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.
| Quote: | 2. Is it possible that in the recent future we
will have a C++ binding for threading? If not, why?
Yes, it is possible that in C++0x we will have a C++ binding for |
threading.
I'm sure that many people would say that we already have POSIX. So, why
would we have to add anything else.
In practice POSIX is not omni-present and perhaps the WG21 can add a
library layer abstracting platform differences, if possible, better
than POSIX and in a more OO way.
That's why I prefer programming in POSIX+C++ than in Ada or any other
language containing an intrinsic concurrent model.
| Quote: | 3. This is maybe a little bit off-topic, but it is said
that Bjarne Stroustrup has been working with
concurrent programming for at least 20 years,
for what reason he (together with committee
members) did not add threading to the language?
C++ predates POSIX? Lack of manpower? Or simply
the complicity?
It might be due to the fact that normalizing concurrent programming is |
a hard work and the committee had better to normalize the existing C++
implementations in 1998.
Now for C++0x, this issue has been raised:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1815.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1907.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1940.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2043.html
Moreover, it requires "testing" that. i.e. before normalizing something
we must have several C++ implementations successfully implementing the
feature.
To get more info about the papers currently proposed:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
---
[ 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 ] |
|
| Back to top |
|
|
Earl Purple
Guest
|
| Posted: Mon Aug 21, 2006 11:07 am Post subject: Re: Threading issue in next standard |
|
|
SuperKoko wrote:
| Quote: | 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.
|
Does a "library facility" mean a "standard" interface that is written
to wrap
what is already there? 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.
| Quote: | 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.
- 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.
- use a class method for thread-creation, not a function pointer.
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.
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.
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.
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.
| Quote: | 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.
---
[ 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 ] |
|
| Back to top |
|
|
kwikius
Guest
|
| Posted: Mon Aug 21, 2006 4:07 pm Post subject: Re: Threading issue in next standard |
|
|
Earl Purple wrote:
<...>
| Quote: | 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.
|
That's easy ... I/O ports.
regards
Andy Little
---
[ 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 ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Mon Aug 21, 2006 4:09 pm Post subject: Re: Threading issue in next standard |
|
|
Earl Purple wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | - 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.
| Quote: | - 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.)
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.)
| Quote: | 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 orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 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 ] |
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Mon Aug 21, 2006 9:12 pm Post subject: Re: Threading issue in next standard |
|
|
kanze wrote:
| Quote: | But you can't do threading in just the library. There are
language level issues that must be addresses, such as memory
synchronization.
|
True. That really is a language issue, because it may be necessary
to use instructions, like test-and-set, or compare-and-swap where
available, that the compiler would not otherwise emit.
Current solutions in that area tend to involve assembly language
library functions or system calls, often with a performance
penalty.
John Nagle
Animats
---
[ 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 ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Wed Aug 23, 2006 4:41 am Post subject: Re: Threading issue in next standard |
|
|
Jiang wrote:
I said that it was highly likely. We can't be 100% sure until
the standard is adopted, but the committee is definitly working
on it, and it seems to have a fairly high priority.
| Quote: | If this is true, I would like to know that:
1. How will the language and library overlap?
|
That is part of what is still under discussion. Some things
must be handled at the language level.
| Quote: | That is, threading will be purposed by library extension
(like boost.thread), or adding new language constructs,
such as keywords like "synchronized"?
|
Or something in between. I'm pretty sure we won't see a
"synchronized" keyword, like the Java fiasco. (At least I hope
so, and to date, I haven't heard anyone proposing it.) And I'm
equally sure that the language itself will be modified to "know"
about threading in some ways---if nothing else, threading will
introduce a whole new world of possible undefined behaviors.
| Quote: | 2. Is it possible that in the recent future we
will have a C++ binding for threading? If not, why?
|
I feel fairly certain that in C++0x, it will be possible to
start threads, join them, and synchronize them, possibly in
different ways (low-level, lock free and mutex or something
similar). What it will look like is still an open topic---if I
had to guess, I'd say that at least parts of it might look
something like boost::threads.
| Quote: | 3. This is maybe a little bit off-topic, but it is said
that Bjarne Stroustrup has been working with
concurrent programming for at least 20 years,
for what reason he (together with committee
members) did not add threading to the language?
|
He wanted to be able to implement it under Unix at the time?
Historically, concurrent programming didn't always involve what
we consider threads today. There are (or at least were) many
models. (What ever happened to the transputer and Occam?)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 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 ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Wed Aug 23, 2006 5:16 pm Post subject: Re: Threading issue in next standard |
|
|
kanze wrote:
Sorry for my poor quote, actuallly I meant the thread issues
*possbly* will be addressed in next standard.
| Quote: | If this is true, I would like to know that:
1. How will the language and library overlap?
That is part of what is still under discussion. Some things
must be handled at the language level.
That is, threading will be purposed by library extension
(like boost.thread), or adding new language constructs,
such as keywords like "synchronized"?
Or something in between. I'm pretty sure we won't see a
"synchronized" keyword, like the Java fiasco. (At least I hope
so, and to date, I haven't heard anyone proposing it.) And I'm
equally sure that the language itself will be modified to "know"
about threading in some ways---if nothing else, threading will
introduce a whole new world of possible undefined behaviors.
|
Agree. And without this kind of knowledge, some basic
constructs can not work easily without special treatment,
for an quick example, Exception handling comes to mind.
| Quote: | 2. Is it possible that in the recent future we
will have a C++ binding for threading? If not, why?
I feel fairly certain that in C++0x, it will be possible to
start threads, join them, and synchronize them, possibly in
different ways (low-level, lock free and mutex or something
similar). What it will look like is still an open topic---if I
had to guess, I'd say that at least parts of it might look
something like boost::threads.
|
That is also my understanding about the current situation.
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.
| Quote: | 3. This is maybe a little bit off-topic, but it is said
that Bjarne Stroustrup has been working with
concurrent programming for at least 20 years,
for what reason he (together with committee
members) did not add threading to the language?
He wanted to be able to implement it under Unix at the time?
|
Really? I am not sure, but Unix(s) at that time does not
have any thread model in my mind.
| Quote: | Historically, concurrent programming didn't always involve what
we consider threads today. There are (or at least were) many
models. (What ever happened to the transputer and Occam?)
|
Yes, what you said is possibly one of the most significant
reason for why we do not have a concurrent programming
model in C++.
---
[ 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 ] |
|
| Back to top |
|
|
Guest
|
| Posted: Wed Aug 23, 2006 6:42 pm Post subject: Re: Threading issue in next standard |
|
|
Jiang wrote:
..
| Quote: | 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.
---
[ 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 ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Wed Aug 23, 2006 6:42 pm Post subject: Re: Threading issue in next standard |
|
|
Jiang wrote:
| Quote: | kanze wrote:
Jiang wrote:
|
[...]
| Quote: | 3. This is maybe a little bit off-topic, but it is said
that Bjarne Stroustrup has been working with
concurrent programming for at least 20 years,
for what reason he (together with committee
members) did not add threading to the language?
He wanted to be able to implement it under Unix at the time?
Really? I am not sure, but Unix(s) at that time does not
have any thread model in my mind.
|
Exactly. Since the OS didn't support concurrency, he didn't put
it in the language.
I've seen some early attempts to implement threaded systems in
C++ on top of an OS which didn't support them. They weren't
pretty.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 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 ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Thu Aug 24, 2006 3:04 am Post subject: Re: Threading issue in next standard |
|
|
SuperKoko wrote:
| Quote: | 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.
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?
The problem is, even we have a thread library, lots of
low level details must be handled by our programmers.
To fight with the complexity of threading, we really need
necessary language level abstraction in my mind.
Just consider this, the read_write_mutex in boost.thread
was removed due to problems with deadlocks. If those
best experts can not handle the low level issues
correctly (although it's rare case, of course), IMHO,
I would like to use the single particular, but controllable
one. Freedom here does not benefit too much for me.
| Quote: | 2. Is it possible that in the recent future we
will have a C++ binding for threading? If not, why?
Yes, it is possible that in C++0x we will have a C++ binding for
threading.
|
Glad to hear that.
| Quote: | I'm sure that many people would say that we already have POSIX. So, why
would we have to add anything else.
In practice POSIX is not omni-present and perhaps the WG21 can add a
library layer abstracting platform differences, if possible, better
than POSIX and in a more OO way.
That's why I prefer programming in POSIX+C++ than in Ada or any other
language containing an intrinsic concurrent model.
|
Yes, without a true C++ binding, threading using c++ always
invokes undefined behavior.
Roger that. I read some of them but not all, thank you for your time.
---
[ 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 ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Thu Aug 24, 2006 4:19 pm Post subject: Re: Threading issue in next standard |
|
|
kuyper (AT) wizard (DOT) net wrote:
| Quote: | 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 don't want to speak for Stroustrup, but at the last meeting,
he definitly gave the impression of concurring with this
consensus.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 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 ] |
|
| Back to top |
|
|
Gerhard Wesp
Guest
|
| Posted: Thu Aug 24, 2006 8:18 pm Post subject: Re: Threading issue in next standard |
|
|
John Nagle <nagle (AT) animats (DOT) com> wrote:
| Quote: | Meanwhile, it would be nice if C++ had some features to
easily generate fast marshalling code. We're going to be
seeing more interprocess and inter-CPU communication.
|
I advocate some form of introspection to iterate over class members.
Then we could write:
struct foo { int a; double b; string s; };
for(auto x in foo) {write_binary(x);}
And it could be used for lots of other tasks as well.
Regards
-Gerhard
---
[ 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 ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Fri Aug 25, 2006 3:49 pm Post subject: Re: Threading issue in next standard |
|
|
Earl Purple wrote:
| Quote: | Jiang wrote:
SuperKoko wrote:
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.
There are 3 locking issues here:
- A mutex. Covers all situations
- A critical section. Only one thread is allowed to access this thread
at a time
- An atomic section of code. This effectively means that all
other threads must wait while this block of code is completed.
With a genuine dual-processor there really are 2 threads
running at a time so this may be harder to enforce.
|
Don't confuse names with principles. Mutex, critical section
and atomic section (as you define it---I've never heard the term
before) all mean more or less the same thing. (Normally, I
would use critical section for the area of code being protected,
and mutex for the mechanism protecting it. Historically, too,
there were other ways of ensuring exclusion in a critical
section---on the processors I started with, I'd disable
interrupts, for example.)
There are also atomic operations, which work without using
external protection.
| Quote: | With a mutex, you have different mutexes but the same mutex
could be locked in multiple parts of the code which clash with
each other
|
I'm not sure what you're trying to say here. But I think your
point is that two different functions need to access the same
data, and thus use the same mutex. In the Java model of
synchronous functions, this works for member data, since all
member functions synchronize on the same data.
Of course, most of the time you use external synchronization,
you are updating several different objects, and need to ensure
that no other thread interrupts between the updates. Which
means synchronizing with the same mutex in functions of
different objects. (In at least one case, I ran the application
as if threads weren't preemptive. The application had exactly
one mutex, which was only released when a thread explicitly
wanted to allow other threads through---typically, when it
needed to wait for IO or something like that. It made thread
safety a lot, lot easier, and on a single processor machine,
total throughput was considerably higher than it would have been
with finer grained locking.)
| Quote: | 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?
It's not a matter of programmers "remembering RAII". RAII is
there so that programmers don't have to remember to release
resources.
|
In the Java model, locks have to be handled by the language,
precisely because there is no RAII. A lock is a resource where
RAII is usually an important simplification.
I'm not really sure about the Jiang's point here. Locks at the
function level don't work well, because the granularity of
locking rarely corresponds to the granularity of a
function---you end up either holding the lock to long, or
twisting your design to make the functions fit the required
locking. And the difference between block level locking and
RAII seems very slim to me:
block locking:
void f()
{
// ...
synchronize mutexObject {
// locked section...
}
// ...
}
RAII:
void f()
{
// ...
{
scoped_lock l( mutexObject ) ;
// locked section...
}
// ...
}
Block locking has the advantage that you don't need to invent a
name for the scoped_lock object. On the other hand, in the RAII
solution, you frequently don't need the inner block, and in
some, very simple cases, you can even write things like:
scoped_lock( mutexObject ), whatever() ;
(This works as long as whatever is a simple expression. Whether
it is a good idea on readability grounds is another question. I
can't say that I really like it, but the possibility does
exist.)
More generally, the RAII idiom also allows things like:
std::auto_ptr< scoped_lock >
f()
{
std::auto_ptr< scoped_lock > l ;
// ...
return l ;
}
Posession of the lock is not tied to function scope.
| Quote: | The problem is, even we have a thread library, lots of
low level details must be handled by our programmers.
Low-level details would be handled by the writers of the
standard libraries rather than by the compiler manufacturers,
who may be different. I would prefer it if my code were
compiled directly in machine code rather than the compiler
having to keep compiling a standard library of templates time
and again.
|
Well, everything ultimately compiles to machine code. I'm not
quite sure what your point is here---it sounds like you are
arguing against the library solution (since in the library
solution, the compiler would have to keep compiler a standard
library again and again).
| Quote: | Also, if the library were to be written on a UNIX system to
wrap pthreads then would it use a header file <cpthread> to
avoid name-clashing or would the entire pthread library be
automatically "included" into your source when you weren't
actually using it directly. Similarly on Windows with their
standard library and on any other platform that has
multi-threading.
|
I don't get this. Why would the compiler have to automatically
include anything, any more than it does for e.g. new or typeid
(both of which depend on "library" functions or classes)?
| Quote: | Just consider this, the read_write_mutex in boost.thread
was removed due to problems with deadlocks.
No matter how good a threads library you write, it is up to
the application-level programmer to ensure that there are no
deadlocks. The purpose of a library is to aid good
programming, not to prevent bad programming. Of course you do
put in some protection so that programmers won't do the wrong
thing.
The potential problem of read-write locks is writer
starvation. If there are always readers about, the writer may
never get a chance to write.
|
That depends on how they are implemented. Normally, I would
expect that as soon as a writer is waiting further read requests
suspend until it has finished.
| Quote: | This can be prevented by adding an addition mutex - the reader
and writer both must acquire the mutex before acquiring the
read-write lock, but there is a difference. The read releases
the mutex immediately on acquiring it, the writer holds onto
the mutex until it gets the read-write lock. That means the
mutex remains locked if there is a writer waiting to write,
and new readers cannot read although the existing ones may
continue reading. In practice this is not a bad thing as
although the readers may wait a bit, they will eventually read
the most updated information.
|
There's no reason to be that complicated. If an implementation
doesn't provide read/write locks, they can easily be simulated
with a single conditional. Regardless of the desired locking
policy.
| Quote: | Now if you have to implement a library on top of what you
already have, then on a POSIX system you would probably
implement read-write locks on top of pthread_rwlock_init etc.
There is, as far as I'm aware no defined behaviour as to
whether writers get priority in such a library so to be safe
you may well add it in to your own.
|
The defined behavior depends partially on the implementation. If
the Thread Execution Scheduling option is supported, read-write
locks are required to work correctly; otherwise, it is
implementation defined. (Solaris documents them as working
correctly, and I suspect that this is true on most
implementations---pthread_rwlock_rdlock will block if there is a
thread waiting to write, even if it doesn't have the lock.)
| Quote: | If those best experts can not handle the low level issues
correctly (although it's rare case, of course), IMHO, I
would like to use the single particular, but controllable
one. Freedom here does not benefit too much for me.
The issues with boost is that they are trying to write a
library for all systems, but different systems do things
differently. On Windows there is no concept of rwlock, you
have to implement the whole thing yourself using just mutex
and semaphore etc.
|
Which shouldn't be that difficult, since they have implemented
conditional variables (which is what you need to implement a
read-write lock).
| Quote: | That would be the same for any "standard" library for threads.
A language feature would mean that your code would be directly
compiled to the relevant machine code.
|
The distinction isn't that black and white, consider typeid and
std::type_info. I don't know what C++ threading will look like
in its final version, but I do know that it will have some
language support, and that there will be library parts as well.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 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 ] |
|
| Back to top |
|
|
Guest
|
| Posted: Sat Aug 26, 2006 4:06 am Post subject: Re: Threading issue in next standard |
|
|
kanze wrote:
| Quote: | kuyper (AT) wizard (DOT) 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.
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.
There might a need for two flavors of observe,
one guaranteed to work when the reads/writes
to i are via aliases and/or outside the compilation
unit, and one that's not.
The assumption here is that, whatever "observable
behavior" exactly means, it's observable by all
the threads running with a common memory
space.
If you think "observe" is redundant with volatile,
try compiling some code that uses a
volatile instance of a class. You'll find
you have to duplicate all the (non-static)
member functions and add a 'volatile'
qualifier to them. Also, using volatile tends to
result in more memory barriers and
register flushing than is really necessary to
safely pass data between threads.
---
[ 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 ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
