"James Kanze" <kanze@alex.gabi-soft.fr> wrote in message
news:867k8xv30a.fsf@alex.gabi-soft.fr...

> I fully expect threading to find its way into the next C++ standard.

What you mean by 'fully'?    With threading we have core issues and library
issues.
The core issues must be covered some way -- specifying requirements on
memory model, multiproc issues, etc.

I'm not sure if one full specification is possible that will be good for all
MT systems. [My knowledge is limited to some processors, architectues and
OS-es, unfortunately people working on the others are not active on this
newsgroup...]     However I think it's possible to define a small number of
classes with fully defined semantics.  Then require implementation to
support at least one, and make it detectable.   As if  the standard leaves
most vital stuff just 'unspecified' or 'defined by implementation' without
constraints   where's the progress?

Library is a more problematic part from the standard's view.    There are
common things in widely used systems.  But also tons of differences. Big
enough to make it impractical to build a common library -- one that people
will actually use without native stuff.
While those using threads now are happy with what they use.    It works well
on the target system. If really needed it can be even ported (by hand or
using wrappers). Who plan to support multiple systems write own wrappers
with careful planning the details.
This happens for a decade -- I don't think anyone would seriously consider
dropping the existing stuff and pick up the standard's whatever it will be.

The basic choices I see for library is:
1. No library a all
2. really narrow library -- only basics, trivially supported on most
considerable systems.
3. fat library -- union of used tools on current systems -- the library
makers must implement them regardless native support, possibly bringing in
big penalty
4. multicolor library

The last one has some tools "optional". To make it usable also introducing
feature detectability, and restrict optinality to a countable set of cases.

The real problematic stuff I came across is: a) interlocked inc/dec,
add/sub.  b) interlocked swap  c) interlocked compare-and-swap  d)
WaitForMultipleObjects.
Those are extremely well usable things if they are supported. If I know I
have them, I design to use them. If not, I'll do things quite differently.
Then, taking the first pass, and findig the "support" is really emulation
leads to trouble.

My preference order is 1 > 4 > 2 > 3.   Yes, I'm serious with putting 1 at
head.

> The C++ standard is silent about this, because it doesn't define a
> MEMBAR.  Any implementation which does define it would have to specify
> this -- given the supposed semantics, I presume that the specification
> would also forbid such code movement.  Any compiler supporting MEMBAR
> on such a platform would have to respect these semantics.

Now, membar is definitely a thing that shall be part of the core language.
Influencing the optimizer/code emitter, and also making possible to create
the optimal code for the desired target (blank, for a big set of current
systems).

Paul
---
[ 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                       ]

On 16 May 2003 10:10:45 -0400, "Balog Pal" <pasa@lib.hu> wrote:

 >"James Kanze" <kanze@alex.gabi-soft.fr> wrote in message
 >news:867k8xv30a.fsf@alex.gabi-soft.fr...
 >
 >> I fully expect threading to find its way into the next C++ standard.
 >
 >What you mean by 'fully'?    With threading we have core issues and library
 >issues.
 >The core issues must be covered some way -- specifying requirements on
 >memory model, multiproc issues, etc.


Several months ago, I started a thread to the effect that it was time
for the Standard to acknowledge threads.  The core example I gave was
to specify whether it's okay to 'delete' memory you got from a 'new'
that executed in a different thread, but in general I was asking for a
beginning.  Surely we can specify the behavior of existing libraries
within a threaded world, I thought.

Boy, was I wrong.  Maybe the committees can do a better job than this
group did.  Then again, this group does include people who sit on or
at least contribute to the standards committee.

Agreed that the Standard *ought* to cover threading issues.  But I'm
not holding my breath waiting for it.
-- jkb


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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                       ]

"Balog Pal" <pasa@lib.hu> writes:

|>  "James Kanze" <kanze@alex.gabi-soft.fr> wrote in message
|>  news:867k8xv30a.fsf@alex.gabi-soft.fr...

|>  > I fully expect threading to find its way into the next C++ standard.

|>  What you mean by 'fully'?

Completely, without doubt.  The word is an adverb modifying "expect",
and makes explicit just how much I expect it.  (I believe this is a
pretty standard English, or at least American English, use, but I
could be wrong -- It's been over 30 years since I've used English on a
regular basis.)

|>  With threading we have core issues and library issues.

This is, IMHO, one of the reasons why we cannot put it off.  One can
argue about the wisdom of adding a regular expression class for
example; even if the standard committee says it isn't important
enough, I can download the boost class, and declare it my standard.  I
can't do this with threading, since the compiler has to play along.

|>  The core issues must be covered some way -- specifying
|>  requirements on memory model, multiproc issues, etc.

This is probably the hardest part.  I don't think that the authors of
the Java specification are particularly stupid, but they got it wrong.

|>  I'm not sure if one full specification is possible that will be
|>  good for all MT systems. [My knowledge is limited to some
|>  processors, architectues and OS-es, unfortunately people working
|>  on the others are not active on this newsgroup...]

There is truthfully a serious risk.  C++ should be implementable on
all architectures.  What happens if some architecture can't support
threading.

IMHO (but I'm really just guessing), this risk is attenuated by the
fact that most of the exotic architectures we have to deal with are
older and simpler, and the problems with things like reordered writes
and multiple processors don't occur.  These issues just work.

|>  However I think it's possible to define a small number of classes
|>  with fully defined semantics.  Then require implementation to
|>  support at least one, and make it detectable.  As if the standard
|>  leaves most vital stuff just 'unspecified' or 'defined by
|>  implementation' without constraints where's the progress?

|>  Library is a more problematic part from the standard's view.
|>  There are common things in widely used systems.  But also tons of
|>  differences. Big enough to make it impractical to build a common
|>  library -- one that people will actually use without native stuff.

There are, in fact, several basic models.  In general, any one can be
implemented in terms of another other.

|>  While those using threads now are happy with what they use.  It
|>  works well on the target system. If really needed it can be even
|>  ported (by hand or using wrappers). Who plan to support multiple
|>  systems write own wrappers with careful planning the details.
|>  This happens for a decade -- I don't think anyone would seriously
|>  consider dropping the existing stuff and pick up the standard's
|>  whatever it will be.

|>  The basic choices I see for library is:
|>  1. No library a all
|>  2. really narrow library -- only basics, trivially supported on
|>  most considerable systems.
|>  3. fat library -- union of used tools on current systems -- the
|>  library makers must implement them regardless native support,
|>  possibly bringing in big penalty
|>  4. multicolor library

I'd go with 2 for starters.  Once we have some concrete experience...

|>  The last one has some tools "optional". To make it usable also
|>  introducing feature detectability, and restrict optinality to a
|>  countable set of cases.

|>  The real problematic stuff I came across is: a) interlocked
|>  inc/dec, add/sub.  b) interlocked swap c) interlocked
|>  compare-and-swap d) WaitForMultipleObjects.

All are easily implementable on just about every platform.  Efficiency
is another question -- on a pre-v9 Sparc, for example, the only real
way to implement an atomic increment or decrement (at least in user
mode) is to use a Mutex:-).

In this case, I would argue that specifying the interface is useful.
Systems which cannot do better use a Mutex.  Those which can do better
do so.

|>  Those are extremely well usable things if they are supported. If I
|>  know I have them, I design to use them. If not, I'll do things
|>  quite differently.  Then, taking the first pass, and findig the
|>  "support" is really emulation leads to trouble.

|>  My preference order is 1 > 4 > 2 > 3.  Yes, I'm serious with
|>  putting 1 at head.

|>  > The C++ standard is silent about this, because it doesn't define
|>  > a MEMBAR.  Any implementation which does define it would have to
|>  > specify this -- given the supposed semantics, I presume that the
|>  > specification would also forbid such code movement.  Any
|>  > compiler supporting MEMBAR on such a platform would have to
|>  > respect these semantics.

|>  Now, membar is definitely a thing that shall be part of the core
|>  language.  Influencing the optimizer/code emitter, and also making
|>  possible to create the optimal code for the desired target (blank,
|>  for a big set of current systems).

I'm not convinced that there is a need for membar per se.  I'd rather
see things like atomic increment and decrement, or requiring the
initialization of local statics to work.  Something along the lines of
pthread_once (but with a C++ style interface) would be nice as well.

--
James Kanze                                  mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                      Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  Tel. +33 1 41 89 80 93

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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                       ]