Topic: What about multithreading?
Author: "Greg" <greghe@pacbell.net>
Date: 15 Sep 2005 05:30:01 GMT Raw View
John Nagle wrote:
> bjarne wrote:
> > graeme prentice wrote:
> >
> >
> >>...
> >>The portability issue is crucial. As it is, there are various
> >>optimisations made by some compilers that are perfectly reasonable in
> >>the single-threaded memory model of the current standard, can
> >>introduce data races in apparently safe multithreaded code. There are
> >>also problems of "word-tearing" on some architectures. I suggest you
> >>read "Threads Cannot be Implemented as a Library"
> >><http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf> if you have
> >>not already done so.
> >
> >
> > Note that the report is written by Hans Boehm (of conservative GC fame)
> >
> >
> >>>Does the compiler need to know the actual hardware it's
> >>>compiling for and access it directly, instead of going through the host
> >>>platform?
> >>
> >>It needs at least some knowledge of the memory model of the target
> >>architecture. It also needs to respect limitations on memory
> >>reordering that are implied by synchronisation primitives.
> >>
> >>
> >>>Bjarne Stroustrup said this 4 or 5 years ago, in a discussion of
> >>>directions for C++
> >>
> >>><Bjarne > (reformatted)...
>
> >>>- No core language facilities (no keywords)
>
> This is about to become more critical as "cell" processors,
> with various forms of semi-shared memory, become available.
> At that point, language support will become essential.
>
> But don't worry. Vendors will ignore the committee and add
> keywords anyway. Here's Microsoft's list of keywords they've
> added so far:
>
> __abstract
> __alignof
> __asm
> __assume
[long list omitted]
Actually, once the extraneous __declspec attributes and the managed
extensions are pared from this list, the remaining keywords lead to the
opposite conclusion: instead of "ignoring the Committee", these
keywords in fact abide by the Standard, specifically 17.4.3.1.2:
Each name that contains a double underscore (__) or begins
with an underscore followed by an upper case letter (2.11) is
reserved to the implementation for any use.
Presumably "any use" would include serving as keywords. I can find
nothing in the Standard that expressly limits keywords to the ones it
enumerates. In fact, the Standard implies otherwise, stating that its
keywords are "unconditionally" treated as such (2.11.1) - which clearly
leaves the door open for implementations to add their own.
Greg
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: ben-public-nospam@decadentplace.org.uk (Ben Hutchings)
Date: Sat, 3 Sep 2005 05:22:07 GMT Raw View
graeme prentice <gp.kiwi@gmail.com> wrote:
> On Fri, 26 Aug 2005 10:19:56 CST, Ben Hutchings wrote:
>
>>
>>Actually, it is both possible and important to make standard C++
>>suitable for multithreading. What's needed is a revised memory model
>>that defines what kinds of inter-thread sharing are and are not safe
>>and provides a framework in which both locking and lockless
>>synchronisation primitives can be defined. Data ownership can remain
>>implicit, as it normally is in today's multithreaded programs.
>>There is little if any need for syntactic change.
>
>
> Is it possible to explain in more detail ??
>
> Apart from the portability issue, if the platform already provides
> synchronization primitives, what benefit is there in changing the C++
> memory model?
The portability issue is crucial. As it is, there are various
optimisations made by some compilers that are perfectly reasonable in
the single-threaded memory model of the current standard, can
introduce data races in apparently safe multithreaded code. There are
also problems of "word-tearing" on some architectures. I suggest you
read "Threads Cannot be Implemented as a Library"
<http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf> if you have
not already done so.
> Does the compiler need to know the actual hardware it's
> compiling for and access it directly, instead of going through the host
> platform?
It needs at least some knowledge of the memory model of the target
architecture. It also needs to respect limitations on memory
reordering that are implied by synchronisation primitives.
> Bjarne Stroustrup said this 4 or 5 years ago, in a discussion of
> directions for C++
>
><Bjarne > (reformatted)
> - Standard library classes
> - No core language facilities (no keywords)
> - Thin interface to platform threads
> - (local) lock objects
> - Example of resource object (RAII)
> - Language guarantees for general concurrency
><>
>
>
> Leaving aside issues of portability, what guarantees does the language
> need to provide to make it more suitable for multithreading?
>
> 1. multiple threads can throw exceptions "concurrently"
> 2. multiple threads can call functions with local static variables that
> have initialization
> 3. documentation of any language facility that needs user
> synchronization (should be none)
> 4. ability to limit/control re-ordering of data access by the compiler
> 5. documentation by the library vendor of what needs synchronization or
> what doesn't
>
> How would number 2 be implemented? If the compiler is going to call an
> OS or platform function, the user needs a choice if that happens, to
> avoid the performance penalty.
An optional part could be added to local static variable declarations
that would cause any dynamic initialisation of them to be
synchronised. However, currently there doesn't seem to be any
consensus on what to do about this.
> Does the user need to know about the memory model?
C++ programmers should not, in general, need to know that much about
it, any more than they do about the current single-threaded memory
model. I believe a standard multi-threaded memory model will be
easier to understand than the variety of mostly poorly described
memory models of current implementations.
--
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert Einstein
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: "bjarne" <bjarne@gmail.com>
Date: Sat, 3 Sep 2005 10:40:03 CST Raw View
graeme prentice wrote:
> ...
> The portability issue is crucial. As it is, there are various
> optimisations made by some compilers that are perfectly reasonable in
> the single-threaded memory model of the current standard, can
> introduce data races in apparently safe multithreaded code. There are
> also problems of "word-tearing" on some architectures. I suggest you
> read "Threads Cannot be Implemented as a Library"
> <http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf> if you have
> not already done so.
Note that the report is written by Hans Boehm (of conservative GC fame)
> > Does the compiler need to know the actual hardware it's
> > compiling for and access it directly, instead of going through the host
> > platform?
>
> It needs at least some knowledge of the memory model of the target
> architecture. It also needs to respect limitations on memory
> reordering that are implied by synchronisation primitives.
>
> > Bjarne Stroustrup said this 4 or 5 years ago, in a discussion of
> > directions for C++
>
> ><Bjarne > (reformatted)
> > - Standard library classes
> > - No core language facilities (no keywords)
> > - Thin interface to platform threads
> > - (local) lock objects
> > - Example of resource object (RAII)
> > - Language guarantees for general concurrency
> ><>
That still looks good. In the standards committee, Hans Boehm is now in
charge of the "language guarantees" bits (mostly memory model) and
Lawrence Crawl (from Sun) in charge of the library issues relating to
concurrency (mostly threads).
-- Bjarne Stroustrup; http://www.research.att.com/~bs
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Mon, 5 Sep 2005 21:45:13 GMT Raw View
bjarne wrote:
> graeme prentice wrote:
>
>
>>...
>>The portability issue is crucial. As it is, there are various
>>optimisations made by some compilers that are perfectly reasonable in
>>the single-threaded memory model of the current standard, can
>>introduce data races in apparently safe multithreaded code. There are
>>also problems of "word-tearing" on some architectures. I suggest you
>>read "Threads Cannot be Implemented as a Library"
>><http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf> if you have
>>not already done so.
>
>
> Note that the report is written by Hans Boehm (of conservative GC fame)
>
>
>>>Does the compiler need to know the actual hardware it's
>>>compiling for and access it directly, instead of going through the host
>>>platform?
>>
>>It needs at least some knowledge of the memory model of the target
>>architecture. It also needs to respect limitations on memory
>>reordering that are implied by synchronisation primitives.
>>
>>
>>>Bjarne Stroustrup said this 4 or 5 years ago, in a discussion of
>>>directions for C++
>>
>>><Bjarne > (reformatted)...
>>>- No core language facilities (no keywords)
This is about to become more critical as "cell" processors,
with various forms of semi-shared memory, become available.
At that point, language support will become essential.
But don't worry. Vendors will ignore the committee and add
keywords anyway. Here's Microsoft's list of keywords they've
added so far:
__abstract
__alignof
__asm
__assume
__based
__box
__cdecl
__declspec
__delegate
__event
__except
__fastcall
__finally
__forceinline
__gc
__hook
__identifier
__if_exists
__if_not_exists
__inline
__int8
__int16
__int32
__int64
__interface
__leave
__m64
__m128
__m128d
__m128i
__multiple_inheritance
__nogc
__noop
__pin
__property
__raise
__sealed
__single_inheritance
__stdcall
__super
__try_cast
__try/__except
__try/__finally
__unhook
__uuidof
__value
__virtual_inheritance
__w64
__wchar_t
deprecated
dllexport
dllimport
naked
noinline
noreturn
novtable
property
selectany
thread
using declaration,
using directive
uuid
wchar_t
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.jamesd.demon.co.uk/csc/faq.html ]
Author: ben-public-nospam@decadentplace.org.uk (Ben Hutchings)
Date: Sat, 27 Aug 2005 05:49:37 GMT Raw View
graeme prentice <gp.kiwi@gmail.com> wrote:
> What's happening about adding multithreading support to the C++
> language?
The following papers have been submitted:
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1680.pdf>
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1682.html>
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1777.pdf>
There's a "strategic plan":
Mhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1815.html>
This paper is in preparation for submission (very) soon:
<http://decadentplace.org.uk/pipermail/cpp-threads_decadentplace.org.uk/2005-August/000593.html>
> Is this in the too hard basket?
I think it's in the "hard, but not too hard" basket.
> What would be the major advantages of adding it?
There would be less need for platform-specific code in multithreaded
programs.
It would remove, or at least clarify, subtle race conditions that
exist in many multithreaded C++ implementations as a result of
speculative execution and/or compiler optimisations even where a
program apparently makes proper use of locks.
It would allow the portable use of lockless synchronisation techniques
to achieve better scalability for multithreaded programs (for example,
double-checked initialisation could be done safely).
It would provide a sound basis for the introduction of additional
synchronisation primitives.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: gp.kiwi@gmail.com (graeme prentice)
Date: Sat, 27 Aug 2005 05:50:39 GMT Raw View
On Fri, 26 Aug 2005 10:19:56 CST, Ben Hutchings wrote:
>
>Actually, it is both possible and important to make standard C++
>suitable for multithreading. What's needed is a revised memory model
>that defines what kinds of inter-thread sharing are and are not safe
>and provides a framework in which both locking and lockless
>synchronisation primitives can be defined. Data ownership can remain
>implicit, as it normally is in today's multithreaded programs.
>There is little if any need for syntactic change.
Is it possible to explain in more detail ??
Apart from the portability issue, if the platform already provides
synchronization primitives, what benefit is there in changing the C++
memory model? Does the compiler need to know the actual hardware it's
compiling for and access it directly, instead of going through the host
platform?
Bjarne Stroustrup said this 4 or 5 years ago, in a discussion of
directions for C++
<Bjarne > (reformatted)
- Standard library classes
- No core language facilities (no keywords)
- Thin interface to platform threads
- (local) lock objects
- Example of resource object (RAII)
- Language guarantees for general concurrency
<>
Leaving aside issues of portability, what guarantees does the language
need to provide to make it more suitable for multithreading?
1. multiple threads can throw exceptions "concurrently"
2. multiple threads can call functions with local static variables that
have initialization
3. documentation of any language facility that needs user
synchronization (should be none)
4. ability to limit/control re-ordering of data access by the compiler
5. documentation by the library vendor of what needs synchronization or
what doesn't
How would number 2 be implemented? If the compiler is going to call an
OS or platform function, the user needs a choice if that happens, to
avoid the performance penalty.
Does the user need to know about the memory model?
Graeme
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Sat, 27 Aug 2005 18:24:28 GMT Raw View
gp.kiwi@gmail.com (graeme prentice) writes:
>>Actually, it is both possible and important to make standard C++
>>suitable for multithreading. What's needed is a revised memory model
>>that defines what kinds of inter-thread sharing are and are not safe
>>and provides a framework in which both locking and lockless
>>synchronisation primitives can be defined. Data ownership can remain
>>implicit, as it normally is in today's multithreaded programs.
>>There is little if any need for syntactic change.
>
>
> Is it possible to explain in more detail ??
>
> Apart from the portability issue, if the platform already provides
> synchronization primitives, what benefit is there in changing the C++
> memory model? Does the compiler need to know the actual hardware it's
> compiling for and access it directly, instead of going through the host
> platform?
It sounds more complicated than it actually is. When you take the
language used in the standard to describe what a program sees when it
reads and writes memory, and you toss in the idea of concurrency on
top of it, you'll find it's impossible to describe the behavior of
synchronization primitives so that they give us the results we expect
from them.
The formal description of how a program sees its memory is very loose
-- just tight enough to work for single threaded programs, but not
enough like the memory model of any particular real system supporting
multithreading to make it possible to specify synchronization. The
challenge is to tighten it up just enough without overspecifying it so
that we rule out existing MT systems or force avoidable
inefficiencies.
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: graeme prentice <gp.kiwi@gmail.com>
Date: Thu, 25 Aug 2005 09:45:25 CST Raw View
What's happening about adding multithreading support to the C++
language? Is this in the too hard basket?
What would be the major advantages of adding it?
Graeme
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 26 Aug 2005 03:26:52 GMT Raw View
graeme prentice wrote:
>
> What's happening about adding multithreading support to the C++
> language? Is this in the too hard basket?
>
> What would be the major advantages of adding it?
>
> Graeme
Every time someone tries to address multithreading, it starts
a religious war. The "I don't need safe locking" people complain.
The "we must use compare and swap" faction comes in. The "we must
never add a new keyword" people grumble. And there's the
"it's an operating system issue" group.
And then someone brings up how multithreading impacts garbage
collection, and vice versa.
The fundamental problem is that doing it right requires
a somewhat different language than C++. The language needs to
be clear on which thread currently owns which data. C++ doesn't
have anything like the facilities needed to do that, and adding
them is too disruptive to the language design.
John Nagle
Animats
"If the ship sinks on an even keel, damage control was successful".
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]
Author: Ben Hutchings <ben-public-nospam@decadentplace.org.uk>
Date: Fri, 26 Aug 2005 10:19:56 CST Raw View
John Nagle <nagle@animats.com> wrote:
> graeme prentice wrote:
>>
>> What's happening about adding multithreading support to the C++
>> language? Is this in the too hard basket?
>>
>> What would be the major advantages of adding it?
>>
>> Graeme
>
> Every time someone tries to address multithreading, it starts
> a religious war.
<snip>
I think that only happens when people post provocative statements
like this:
> The fundamental problem is that doing it right requires
> a somewhat different language than C++. The language needs to
> be clear on which thread currently owns which data. C++ doesn't
> have anything like the facilities needed to do that, and adding
> them is too disruptive to the language design.
Actually, it is both possible and important to make standard C++
suitable for multithreading. What's needed is a revised memory model
that defines what kinds of inter-thread sharing are and are not safe
and provides a framework in which both locking and lockless
synchronisation primitives can be defined. Data ownership can remain
implicit, as it normally is in today's multithreaded programs.
There is little if any need for syntactic change.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
---
[ 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.jamesd.demon.co.uk/csc/faq.html ]