Zeisel Helmut wrote:
>
> In article <381E7B5B.5A7E8900@nonexistant.com>, "Robert O'Dowd" <nospam@nonexistant.com> writes:
> >  This concern could be addressed in the standard with
> >a simple introductory statement something like the following.
> >
> >
> >3)  If a variable is being modified in one thread of execution,
> >     the result returned to another thread performing read-only
> >     access is implementation defined.
> >
>
> When do you consider two variables as different?
> Assume that you have two copies of an std::string
> and you modify these (different?) variables in two threads.

What about the following definition:

An object A is considered part of another object B, if
a call to the destructor of A would also cause B to be
destructed.

Of course, the "being part of"-relation may change with time,
f.ex. with strstreams, foo.str() makes the character string a
non-part of the stream, while foo.freeze(0) makes it a part
again.

>
> Can you safely modify a copy of the string
> in one thread when you do not access the result
> in a different thread?

Since the characters in std::string are always part of the
string according to the above definition, modifying two
different std::strings would have to be safe even if they
share the representation in the beginning.

>
> The standard allows that std::string might internally use
> reference counting. Clearly this reference counting must be locked
> to be thread safe.

Or alternative mechanisms (like atomic increment and atomic
decrement-and-check) must be applied, if supported by the
platform.

>
> What operations on std::strig are safe according to your definition?

Calling two const member functions on the same object concurrently.
Calling arbitrary member functions on different objects concurrently.

>
> What about other objects (of non built-in type) in the C++ lib?

The same.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> wrote:
> Tom Payne wrote:
>>
>> Robert O'Dowd <nospam@nonexistant.com> wrote:
>>
>>> As I understand these things, one reason that the C and C++
>>> standards do not explicitly consider issues related to
>>> multi-threading is that the committee did not want to prevent the
>>> languages being used on systems that do not support threading.
>>> Introducing a specific requirement for threading support would
>>> seriously impact on the value of C/C++ on those systems.
>>
>> One can implement multithreaded programs on any system on which
>> setjmp and longjmp can be implemented.

> Yes, but this will not make the library thread-safe.

Of course not.  My point is that addressing the issue of threads
(within the standard) will not preclude any systems that can support
the current standard(s).

Tom Payne
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <381F32F9.77895441@tribble.com>,
David R Tribble  <david@tribble.com> wrote:
>And that's the problem with both ISO C and ISO C++ - both define
>standard library functions that require extra effort on the part of
>implementors in order to make them thread-safe.

*sigh*.  And we also had a proposal for strsep(), which is a nice replacement
for everything that's wrong with strtok().

>But it would be a step in the right direction for future issues of
>thread safety, for both C and C++, if their libraries didn't rely
>on static data at all.

True enough.

-s
--
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

: I proposed replacements for all the standard C library functions
: (there are only about eight or so) that rely on global/static data
: between calls, which renders them thread-unsafe right out of the
: box.  (See http://david.tribble.com/text/c9xthr.txt .)  It was based
: on existing practice on POSIX systems.   My proposal was rejected.

that would be unfortunate.  the customers of my company's
implmentation are provided with thread-safe versions of _all_
functions in the C library (uh.. the C90 library.. we've managed to
neglect the normative addendum with almost _no_ complaints).  given
things like <tgmath.h>, even requiring an implementor to find a way to
implement a thread-safe version of strtok() sounds like childs' play..

 --xmsb
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Helmut Zeisel <zeisel@my-deja.com> writes:
> > >
> > > Every library or compiler vendor can claim that its C++ library is
> > > "thread safe", but in reality the libraries can behave differently.
> >
> > [Joachim replied:]
> > In theory, yes, but I don't think it is that bad even now. To start
> > with, there is the openly available SGI implementation which carefully
> > defines what it means by being thread-safe.
>
> If this were true, why is it so difficult that the ISO committee
> adopted that definition?

Because the ISO committee would have to come up with one single
solution that everybody can accept. It would have to define all the
details and get them agreed. I'm not saying that it can't be done, or
that wouldn't be an important step forward, only that it is not
easy. Even the C committee hasn't managed to to it!

> Does the SGI lib just cover the "STL" or does it also cover
> std::string? Internally, std::string might use reference counting.
> Is this reference counting thread safe?

Recent versions do have the standard string class (and all associated
templates), earlier versions didn't. There is also an alternative,
non-standard rope class. They are both thread-safe.

> But we are able to make a contract: you (or some third party)
> provide(s) ISO C++ and we port our programs.  If problems occur, it
> is clear who has to fix which part.  If threads are involved, this
> is no longer clear.  Is the library not thread safe or did we just
> use the library in the wrong (undefined) way?

Again, you cannot do this in C either. What you substituted in the C
case was "you provide a standard C implementation which (beyond the
standard requirements) additionally complies with thread-safety as
defined by pthreads."  You can do same with C++: just replace the
thread-safety definition of pthreads with that from the SGI STL. By
the way, it is worth reading SGI's definition of thread-safety at
http://www.sgi.com/Technology/STL/thread_safety.html

> > Note also, that C has done quite well without such a standard, and
> > this  was the other point I was trying to get across, namely that
> > widely followed conventions are bound to develop over time.
>
> Indeed, and the earlier you start, the earlier you can finish.

Agreed.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <x51za7fjlg.fsf@soft.mercury.bc.ca>, Joachim Achtzehnter <joachim@kraut.bc.ca> writes:
>
>Helmut Zeisel <zeisel@my-deja.com> writes:
>> >
>> > [Joachim replied:]
>> > To start
>> > with, there is the openly available SGI implementation which carefully
>> > defines what it means by being thread-safe.
>>
>> If this were true, why is it so difficult that the ISO committee
>> adopted that definition?
>
>Because the ISO committee would have to come up with one single
>solution that everybody can accept. It would have to define all the
>details and get them agreed. I'm not saying that it can't be done, or
>that wouldn't be an important step forward, only that it is not
>easy. Even the C committee hasn't managed to to it!
>
...
>
>Again, you cannot do this in C either. What you substituted in the C
>case was "you provide a standard C implementation which (beyond the
>standard requirements) additionally complies with thread-safety as
>defined by pthreads."  You can do same with C++: just replace the
>thread-safety definition of pthreads with that from the SGI STL. By
>the way, it is worth reading SGI's definition of thread-safety at
>http://www.sgi.com/Technology/STL/thread_safety.html
>

As you said above, SGI's definition is a good starting point,
it is, however, not detailed enough e.g. for the purpose of a contract.
In particular, I am missing a definition of "distinct"
when they speak about "distinct containers".
It is not completely clear what "distinct" strings should be
(when reference counting is used) or when
two i/ostreams should be "distinct" (they can use the same streambuf).

To sum up, this means that we still have to stick to our own library
(where we have the control over thread-safeness ourselves)
and can only very slowly move to the standard library.

Helmut



--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tom Payne wrote:
>
> Robert O'Dowd <nospam@nonexistant.com> wrote:
>
>> As I understand these things, one reason that the C and C++
>> standards do not explicitly consider issues related to
>> multi-threading is that the committee did not want to prevent the
>> languages being used on systems that do not support threading.
>> Introducing a specific requirement for threading support would
>> seriously impact on the value of C/C++ on those systems.
>
> One can implement multithreaded programs on any system on which
> setjmp and longjmp can be implemented.

Yes, but this will not make the library thread-safe.  Consider
strtok() and localtime(), among others, which rely on modifiable
global/static storage across calls.  setjmp()/longjmp() may solve
the multithreaded scheduling problem, but it won't solve the problem
of shared global memory among multiple threads.

As I've said before, eliminating the dependency on writable global
data in all of the standard library functions would be a step in the
right direction towards thread-safety.

-- David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38145573@webpc1.vai.co.at>, zeisel@vai.co.at wrote:
<snip snip>
>For the next version of the standard, however, I would wish that
>there will be some minimal standardization of threads in C++.
>If it really is so difficult to find a "univesral thread model",
>I even would be satisfied if this standardization
>is done for a single thread model, say POSIX or WIN32 threads.
>Hopefully it will not be too difficult to generalize
>this special solution to other thread models.
>
>Helmut

        I doubt that C++ will every have a threading model in its standard.
Even the very concept of concurrency issues are explicitly left as
implementation defined. Although I agree with your sentiment, I also believe
this is the correct decision for the scope of the language standard.

        What's really needed, as we move standard C++ usage into a higher
level model, are environment standards that conform to an object paradigm and
integrate with the language better. How about a POSIX object model (POSIX++)?
It would be really nice not to have to convert to plain ol' C to get at my
basic OS features like concurrency and directory navigation. The biggest thing
preventing this kind of effort up (besides stubborness of c bigots :-)) is the
lack of a standard ABI and name mangeling. I'd LOVE to see some kind of
construct like extern "ANSIC++" {...} or extern "POSIX" {...} that put
compilers into a special standard integration mode for compiling and linking
objects/method declared within the construct. This would allow the compiler
implementors to continue with their (admirable) efforts of saving every cycle
and performing platform-specific optimizations while allowing the developers
to say, "Hey, this code has to link with external standard stuff. Don't
optimize it away.", whenever calls are made to the standard ABI. I think a
standard C++ name mangeling/method calling/object size convention could be
defined that fits the average case without too much overhead. Any code not
declared within such a confine is free to be optimized to heck. Don't pay for
what you don't use!

        FWIW, I've had very good success in the past with ObjectSpace's
system<toolkit> product for doing platform independent development over UNIX
and Windows. Unfortunately that company appears to have greatly reduced its
focus on C++ and has moved over to Java. I've been forced to start developing
my own abstractions which I will probably sell or release as open source some
time in the future. They don't seem too interested in bringing ANSI standard
features into their product like namespaces and true exception handling.

        regards,

                Ben Scherrey
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

zeisel@vai.co.at (Zeisel Helmut) writes:
>
> Joachim Achtzehnter <joachim@kraut.bc.ca> writes:
> >
> > The way I see it, neither C nor C++ specify anything about
> > threads. In what sense, then, is "C and pthreads" better than
> > "C++ and pthreads"?
>
> It is true that the C standard does not say anything about threads,
> but POSIX defines pthreads and defines what "thread safe" should
> mean for ANSI C and its library.  So "C and pthreads" is a well
> defined portable combination.

But pthreads are just one of several thread models you have to deal
with when you talk about "portable" code. Another important one is
obviously Win32 threads, and there are probably others. So, I don't
think you can say that there is ONE well defined combination.

> > As far as threads are concerned, for both C and C++ one can
> > use threads very successfully, but one must carefully choose
> > libraries that are thread-safe.
>
> That is exactly the problem: There exists no common definition
> what "thread safe" should mean for the C++ library.

Again, I would maintain that this situation is not fundamentally
different between C and C++, in both cases the language standards say
nothing about threads. What is true, however, is that in the case of C
there has been more time for implementations to settle on conventions
for behaviour that goes beyond the standard. What it means to be
thread-safe is one such area. If you go back a few years to a time
when the C standard was at the same stage in its evolution where C++
is now, you would have found big differences in the thread-safety
of standard libraries.

> Every library or compiler vendor can claim that its C++ library is
> "thread safe", but in reality the libraries can behave differently.

In theory, yes, but I don't think it is that bad even now. To start
with, there is the openly available SGI implementation which carefully
defines what it means by being thread-safe. Other implementations that
now claim to be thread-safe make more or less similar
assumptions. Many early releases of C++ standard libraries were not,
and didn't claim to be thread-safe, but the situation is already much
better now.

> Fortunately it is true that in practice we also have no real
> problems with using C++ in threaded program - but just by trial and
> error and common sense, whthout exact knowledge what will work on
> the next machine we have to port our code...
>
> It is, however, difficult to switch to the standard library when we
> have no guarantee that thread safe versions exist.

At this point, there isn't even a guarantee that a correctly
implemented standard library exists, quite aside from the thread
question.

> That multi threaded programs work for the part of the standard
> library we use, however, is the reason why I think it should not be
> so difficult to find a common definition for "thread seafety" of the
> C++ library.

Don't know how difficult this would be. I don't disagree with you,
though. It certainly would be beneficial if the language had something
to say about threads. But my point was that you can't use C as an
example, because C doesn't have "one" standard for threads either. If
you had made a comparison with Java I wouldn't have started this
discussion.

Note also, that C has done quite well without such a standard, and this
was the other point I was trying to get across, namely that widely
followed conventions are bound to develop over time.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Benjamin Scherrey wrote:
>
> In article <38145573@webpc1.vai.co.at>, zeisel@vai.co.at wrote:
> <snip snip>
> >For the next version of the standard, however, I would wish that
> >there will be some minimal standardization of threads in C++.
> >If it really is so difficult to find a "univesral thread model",
> >I even would be satisfied if this standardization
> >is done for a single thread model, say POSIX or WIN32 threads.
> >Hopefully it will not be too difficult to generalize
> >this special solution to other thread models.
> >
> >Helmut
>
>         I doubt that C++ will every have a threading model in its standard.
> Even the very concept of concurrency issues are explicitly left as
> implementation defined. Although I agree with your sentiment, I also believe
> this is the correct decision for the scope of the language standard.

As I understand these things, one reason that the C and C++ standards do
not
explicitly consider issues related to multi-threading is that the
committee
did not want to prevent the languages being used on systems that do not
support threading.  Introducing a specific requirement for threading
support would seriously impact on the value of C/C++ on those systems.

Most multiple threading concerns arise because of the need to serialise
certain sequences of actions (such as reading/writing of a shared
data member).  This concern could be addressed in the standard with
a simple introductory statement something like the following.

Some systems support development of computer programs that support
multiple threads of control in a single process.  Such programs
are referred to as "multi-threaded". This standard includes no
specific requirement for any support of development of multi-threaded
software.

Any function written in C/C++ may be employed in a multi-threaded
program.  In a multi-threaded program, the following observations
may be made.

1)  The result of simultaneous modification of any variable by
     two separate threads of execution is implementation defined.
     It is necessary for compliant applications to ensure that
     any modifications to a variable are ordered in a way that
     prevents simultaneous modification by distinct threads
     of execution.

2)  Multiple threads of execution may perform read-only access
     of any variable.  Each thread will receive the same value.

3)  If a variable is being modified in one thread of execution,
     the result returned to another thread performing read-only
     access is implementation defined.

4)  Access to a variable through a reference is treated as an access
     to the variable itself.

A compliant compiler is not required to diagnose any of the above
situations where behaviour is undefined, but may choose to do
so.

>
>         What's really needed, as we move standard C++ usage into a higher
> level model, are environment standards that conform to an object paradigm and
> integrate with the language better. How about a POSIX object model (POSIX++)?
> It would be really nice not to have to convert to plain ol' C to get at my
> basic OS features like concurrency and directory navigation. The biggest thing
> preventing this kind of effort up (besides stubborness of c bigots :-)) is the
> lack of a standard ABI and name mangeling. I'd LOVE to see some kind of
> construct like extern "ANSIC++" {...} or extern "POSIX" {...} that put
> compilers into a special standard integration mode for compiling and linking
> objects/method declared within the construct. This would allow the compiler
> implementors to continue with their (admirable) efforts of saving every cycle
> and performing platform-specific optimizations while allowing the developers
> to say, "Hey, this code has to link with external standard stuff. Don't
> optimize it away.", whenever calls are made to the standard ABI. I think a
> standard C++ name mangeling/method calling/object size convention could be
> defined that fits the average case without too much overhead. Any code not
> declared within such a confine is free to be optimized to heck. Don't pay for
> what you don't use!

The problem is that, to support this, it would also be necessary to
standardise
the layout of data members and techniques for implementing member
functions of
classes and structs.  Or put severe limitations on what type can be
passed as
arguments to functions or can be returned.

One reason that different compiler vendors are encouraged to use
different
name mangling schemes is to give them freedom with those implementation
details.  Any attempt to standardise struct/class layout would probably
be inefficient on some systems.  It would also probably force
standardisation
of things like the bitwise representation of basic types, that is
explicitly not tied down in the standard.

There would also be the temptation for compiler writers to use the
"standard"
struct layout and name mangling scheme by default in their compilers.
That would support interoperability between compilers, with the
potential
loss of performance.

>
>         FWIW, I've had very good success in the past with ObjectSpace's
> system<toolkit> product for doing platform independent development over UNIX
> and Windows. Unfortunately that company appears to have greatly reduced its
> focus on C++ and has moved over to Java. I've been forced to start developing
> my own abstractions which I will probably sell or release as open source some
> time in the future. They don't seem too interested in bringing ANSI standard
> features into their product like namespaces and true exception handling.
>

-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 8259 6546
MOD/DSTO                     Fax    +61 (8) 8259 5139
P.O. Box 1500                       Email:
robert.odowd@dsto.defence.gov.au
Salisbury, South Australia, 5108

Disclaimer: Opinions above are mine and may be worth what you paid for
them
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7viq3h$14qa@news2.newsguy.com>,
  scherrey@switchco.com (Benjamin Scherrey) wrote:
> In article <38145573@webpc1.vai.co.at>, zeisel@vai.co.at wrote:
> <snip snip>
> >For the next version of the standard, however, I would wish that
> >there will be some minimal standardization of threads in C++.
> >If it really is so difficult to find a "univesral thread model",
> >I even would be satisfied if this standardization
> >is done for a single thread model, say POSIX or WIN32 threads.
> >Hopefully it will not be too difficult to generalize
> >this special solution to other thread models.
> >
> >Helmut
>
>         I doubt that C++ will every have a threading model in its
standard.
> Even the very concept of concurrency issues are explicitly left as
> implementation defined. Although I agree with your sentiment, I also
believe
> this is the correct decision for the scope of the language standard.
>
>         What's really needed, as we move standard C++ usage into a
higher
> level model, are environment standards that conform to an object
paradigm and
> integrate with the language better. How about a POSIX object model
(POSIX++)?

Maybe I should weaken my wish.
I would just be satisfied if there existed any
standard for thread safe C++,
might it be defined in the ISO C++ language
or be defined by POSIX, by the OMG
or by any other institution.

At the moment, however, nobody really wants to
provide such a definition.

>
>         FWIW, I've had very good success in the past with
ObjectSpace's
> system<toolkit> product for doing platform independent development
over UNIX
> and Windows.

We have developed such a framework ourselves.
We can, however, use only small parts
of the C++ standard library because we have no information
how thread-safe the C++ standard library
will be on the next platform we have to use.
Instead of reinventing the wheel, however,
I would prefer to use standardized components.

Helmut


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <x5904hzlss.fsf@soft.mercury.bc.ca>,
  Joachim Achtzehnter <joachim@kraut.bc.ca> wrote:
> zeisel@vai.co.at (Zeisel Helmut) writes:
> >
> > Joachim Achtzehnter <joachim@kraut.bc.ca> writes:
> > >
> > > The way I see it, neither C nor C++ specify anything about
> > > threads. In what sense, then, is "C and pthreads" better than
> > > "C++ and pthreads"?
> >
> > It is true that the C standard does not say anything about threads,
> > but POSIX defines pthreads and defines what "thread safe" should
> > mean for ANSI C and its library.  So "C and pthreads" is a well
> > defined portable combination.
>
> But pthreads are just one of several thread models you have to deal
> with when you talk about "portable" code. Another important one is
> obviously Win32 threads, and there are probably others. So, I don't
> think you can say that there is ONE well defined combination.
>

We do not need a single one and true definition.
At the moment, however,
we guarantee that we can provide our system
for WIN32 and for every platform that supports pthreads.
The price we have to pay, however, is that
we have to restrict ourselves to
only small parts of the C++ library,
otherwise we had no control over the thread safety.

> > > As far as threads are concerned, for both C and C++ one can
> > > use threads very successfully, but one must carefully choose
> > > libraries that are thread-safe.
> >
> > That is exactly the problem: There exists no common definition
> > what "thread safe" should mean for the C++ library.
>
> Again, I would maintain that this situation is not fundamentally
> different between C and C++, in both cases the language standards say
> nothing about threads.

It does not matter to us whether "threads"
are defined in the language definition or somewhere
else. In the case of C, such a definition
exists, namely POSIX (and WIN32);
in the case of C++, however, nothing exists.

>
> > Every library or compiler vendor can claim that its C++ library is
> > "thread safe", but in reality the libraries can behave differently.
>
> In theory, yes, but I don't think it is that bad even now. To start
> with, there is the openly available SGI implementation which carefully
> defines what it means by being thread-safe.

If this were true, why is it so difficult that the ISO
committee adopted that definition?

Besides from that,
we have a thread-safe library developed ourselves.
Maybe you can imagine that it is difficult to
tell the people to switch to "just another" library
(which may or may not exist on the next platform we have to use)
It would be much easier if we can switch just to
THE standard library.

And, just another point:
Does the SGI lib just cover the "STL" or does it also cover
std::string? Internally, std::string might use reference counting.
Is this reference counting thread safe?

> >
> > It is, however, difficult to switch to the standard library when we
> > have no guarantee that thread safe versions exist.
>
> At this point, there isn't even a guarantee that a correctly
> implemented standard library exists, quite aside from the thread
> question.
>

But we are able to make a contract:
you (or some third party) provide(s) ISO C++ and we port our programs.
If problems occur, it is clear who has to fix which part.
If threads are involved, this is no longer clear.
Is the library not thread safe
or did we just use the library in the
wrong (undefined) way?

> It certainly would be beneficial if the language had something
> to say about threads. But my point was that you can't use C as an
> example, because C doesn't have "one" standard for threads either.

As I said alreday, there is not "one" standard,
but there exist well defined standards.

> If
> you had made a comparison with Java I wouldn't have started this
> discussion.

I think it would be a bad idea if people switched
from C++ to Java just because Java offered
a defined thread model.
In our company, however, people consider that change.

> Note also, that C has done quite well without such a standard, and
this
> was the other point I was trying to get across, namely that widely
> followed conventions are bound to develop over time.
>

Indeed, and the earlier you start, the earlier you can finish.

Helmut


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <381E7B5B.5A7E8900@nonexistant.com>, "Robert O'Dowd" <nospam@nonexistant.com> writes:
>  This concern could be addressed in the standard with
>a simple introductory statement something like the following.
>
>
>3)  If a variable is being modified in one thread of execution,
>     the result returned to another thread performing read-only
>     access is implementation defined.
>

When do you consider two variables as different?
Assume that you have two copies of an std::string
and you modify these (different?) variables in two threads.

Can you safely modify a copy of the string
in one thread when you do not access the result
in a different thread?

The standard allows that std::string might internally use
reference counting. Clearly this reference counting must be locked
to be thread safe.

What operations on std::strig are safe according to your definition?

What about other objects (of non built-in type) in the C++ lib?

Helmut


--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Robert O'Dowd <nospam@nonexistant.com> wrote:

> As I understand these things, one reason that the C and C++
> standards do not explicitly consider issues related to
> multi-threading is that the committee did not want to prevent the
> languages being used on systems that do not support threading.
> Introducing a specific requirement for threading support would
> seriously impact on the value of C/C++ on those systems.

One can implement multithreaded programs on any system on which
setjmp and longjmp can be implemented.

Tom Payne
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[comp.std.c added to the list]

Joachim Achtzehnter wrote:
> The way I see it, neither C nor C++ specify anything about threads.
> ...
> As far as threads are concerned, for both C and C++ one can use
> threads very successfully, but one must carefully choose libraries
> that are thread-safe.

And that's the problem with both ISO C and ISO C++ - both define
standard library functions that require extra effort on the part of
implementors in order to make them thread-safe.

I proposed replacements for all the standard C library functions
(there are only about eight or so) that rely on global/static data
between calls, which renders them thread-unsafe right out of the
box.  (See http://david.tribble.com/text/c9xthr.txt .)  It was based
on existing practice on POSIX systems.   My proposal was rejected.

But it would be a step in the right direction for future issues of
thread safety, for both C and C++, if their libraries didn't rely
on static data at all.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
>
> Zeisel Helmut wrote in message <38145573@webpc1.vai.co.at>...
>> For the next version of the standard, however, I would wish that
>> there will be some minimal standardization of threads in C++.
>
> And security, and a GUI, and a component model? Even Bjarne's
> rice cooker might have trouble if we're not careful.
>
> ...
> Next after that would be some portable way of navigating a directory
> tree.

Or even a way of portably specifying a filename.  (A la Common LISP.)

-- David R. Tribble, david@tribble.com, http://www.david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

zeisel@vai.co.at (Zeisel Helmut) writes:
>
> With the current C++ standard, however, C and pthreads is a better
> solution for writing PORTABLE multithreaded code than ISO C++.

Can you explain your reasoning?

The way I see it, neither C nor C++ specify anything about threads. In
what sense, then, is "C and pthreads" better than "C++ and pthreads"?

Independent of threading issues, it is certainly true at this point in
time that C is more portable than C++ in practise because the C++
standard is relatively new and compilers haven't caught up with it
yet. But this has little to do with threads.

As far as threads are concerned, for both C and C++ one can use
threads very successfully, but one must carefully choose libraries
that are thread-safe.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <x54sfcodew.fsf@soft.mercury.bc.ca>, Joachim Achtzehnter <joachim@kraut.bc.ca> writes:
>zeisel@vai.co.at (Zeisel Helmut) writes:
>>
>> With the current C++ standard, however, C and pthreads is a better
>> solution for writing PORTABLE multithreaded code than ISO C++.
>
>Can you explain your reasoning?
>
>The way I see it, neither C nor C++ specify anything about threads. In
>what sense, then, is "C and pthreads" better than "C++ and pthreads"?
>

It is true that the C standard does not say anything
about threads,
but POSIX defines pthreads
and defines what "thread safe" should mean for
ANSI C and its library.
So "C and pthreads"
is a well defined portable combination.

>
>As far as threads are concerned, for both C and C++ one can use
>threads very successfully, but one must carefully choose libraries
>that are thread-safe.
>

That is exactly the problem:
There exists no common definition what
"thread safe" should mean for the C++ library.
Every library or compiler
vendor can claim that its C++ library is
"thread safe", but in reality the libraries
can behave differently.

Fortunately it is true that in practice we also have no real
problems with using C++ in threaded program -
but just by trial and error and common sense,
whthout exact knowledge what will work
on the next machine we have to port our code.
In addition in most places we use our own library (dated before
the definition of the standard)
where we could add ourselves the code to make it threadsafe.
It is, however, difficult to switch
to the standard library when we have
no guarantee that thread safe versions exist.

That multi threaded programs work
for the part of the standard library we use,
however, is the reason why I think it should not be so difficult
to find a common definition for "thread seafety" of the C++ library.

Helmut



--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1OkR3.7471$S7.659512@newscene.newscene.com>, "Al Stevens" <alstevens@midifitz.com> writes:
>Steve Clamage wrote in message <7uokt6$oac$1@engnews1.eng.sun.com>...
>>That will depend on whether suitable definitions can be
>>found that will satisfy everyone.  I don't forsee getting
>>agreement on what thread model should be used.
>
>In 1989, Bjarne said in an interview, "It's been well known for the last 30
>years or so that next year concurrency will be very important. I did my PhD
>on concurrency issues, and I came out of Cambridge knowing 40 ways of
>getting it wrong. I was sure that I did not know a single way of getting it
>right for everybody. From that observation came the policy for C++ that we
>don't put concurrency features into the language."

AFAIK Bjarne Stroustrup also wants that
C++ can be used in every field where C can be used.

With the current C++ standard, however,
C and pthreads is a better solution for
writing PORTABLE multithreaded code
than ISO C++.

So I do not think that Bjarne Stroustrup
still wants concurrency be completely excluded from C++ standardization.

Helmut


--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>In 1989, Bjarne said in an interview...

Correction. That interview was in 1992. Sorry.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:

> Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
>
> >Steve Clamage wrote:
>
> >> That will depend on whether suitable definitions can be
> >> found that will satisfy everyone.  I don't forsee getting
> >> agreement on what thread model should be used.
>
> >My problem is that I don't know the arguments against
> >the thread-model.
>
> The problem is that there are so many incompatible thread
> models to choose from, and each model has advantages and
> disadvantages.

Could you give me pointers ? ('cause I know only
one thread model)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7usftf$8r6$1@panix3.panix.com>, comeau@panix.com (Greg Comeau) writes:
>In article <38102576@webpc1.vai.co.at> zeisel@vai.co.at writes:
>>
>>So the good news is that the members of the C++ committee accept their
>>responsibility.
>
>The most direct cost (just for the meetings) of the Standard has been
>thousands of hours and millions of dollars spent.  The indirect cost
>is magnitudes that.  So, yes, they do, quite seriously.
>

My intent was not to criticize the C++ committee in any way.
I just wanted to say that I am happy that the C++ committe
did not say that POSIX or someone else should do the
work of standardization of threads in ISO C++.

>
>FWIW, the committee has been talking about aspects of this since
>its inception.  And many papers were written about it (both generally
>and about the SL).  But as Steve says, if something like this needs
>to be written in stone, as general purpose and for all to use portably
>etc, then it need due focused consideration.  That this has not occurred
>exhibits that it's needed the time it has taken so far.
>

I got the impression that threads were excluded from the
current version of the C++ standard because there were
many more important things to standardize.

For the next version of the standard, however, I would wish that
there will be some minimal standardization of threads in C++.
If it really is so difficult to find a "univesral thread model",
I even would be satisfied if this standardization
is done for a single thread model, say POSIX or WIN32 threads.
Hopefully it will not be too difficult to generalize
this special solution to other thread models.

Helmut

--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Zeisel Helmut wrote in message <38145573@webpc1.vai.co.at>...
>
>For the next version of the standard, however, I would wish that
>there will be some minimal standardization of threads in C++.

And security, and a GUI, and a component model? Even Bjarne's
rice cooker might have trouble if we're not careful.

I would hold back on this one. If you want pthreads, you've already
got it. I would personally prefer to see more effort on separating the
core language from the library. (It isn't clear whether something like
std::uncaught_exception is implemented by the compiler vendor or
the library vendor.) Next after that would be some portable way of
navigating a directory tree.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

>Steve Clamage wrote:

>> The problem is that there are so many incompatible thread
>> models to choose from, and each model has advantages and
>> disadvantages.

>Could you give me pointers ? ('cause I know only
>one thread model)

Off the top of my head, threads in Ada, Java, POSIX, and
MS Windows are all different, at least in detail.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
....
> got it. I would personally prefer to see more effort on separating the
> core language from the library. (It isn't clear whether something like
> std::uncaught_exception is implemented by the compiler vendor or
> the library vendor.) Next after that would be some portable way of
> navigating a directory tree.

The standard describes the whole implementation, which includes the
hardware, the operating system, the compiler, the standard library, and
the linker. It's entirely outside the scope of the standard to decide
whether or how implementation of various features is to be divided among
those different parts. For all that the standard can or should care,
every feature of C++ could be built directly into the hardware.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> I would personally prefer to see more effort on separating the
> core language from the library. (It isn't clear whether something like
> std::uncaught_exception is implemented by the compiler vendor or
> the library vendor.)

I don't know whether this would be good. Java took the approach of melting
together the language and the libraries, and to good advantage.

type_info, uncaught_exception etc. are things that you cannot easily and
elegantly get without having the language and library co-operate.


Andrei
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan <K.Hagan@thermoteknix.co.uk> wrote in article
<newscache$rdb7kf$yfo$1@firewall.thermoteknix.co.uk>...

> Zeisel Helmut wrote in message <38145573@webpc1.vai.co.at>...
> >
> >For the next version of the standard, however, I would wish that
> >there will be some minimal standardization of threads in C++.
>
> And security, and a GUI, and a component model? Even Bjarne's
> rice cooker might have trouble if we're not careful.
>
> I would hold back on this one. If you want pthreads, you've already
> got it.

I disagree.  pthreads has a strong C bias - its thread cancelation model is
very awkward to use in combination with C++'s stack unwinding.  I ended up
rewriting most of what pthreads already appears to offer to straighten that
one out.

In general, I believe that a minimal standard thread library spec, one that
integrates well with C++'s 'Resource Aquisition is Initialization' (RAI)
idiom would be most useful.  To see why, just try to write a portable CORBA
server in C++.

What we can learn from pthreads is that a thread library doesn't have to be
big to be useful.

- Wil

Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote in message <7uokt6$oac$1@engnews1.eng.sun.com>...
>That will depend on whether suitable definitions can be
>found that will satisfy everyone.  I don't forsee getting
>agreement on what thread model should be used.

In 1989, Bjarne said in an interview, "It's been well known for the last 30
years or so that next year concurrency will be very important. I did my PhD
on concurrency issues, and I came out of Cambridge knowing 40 ways of
getting it wrong. I was sure that I did not know a single way of getting it
right for everybody. From that observation came the policy for C++ that we
don't put concurrency features into 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:

> I would hold back on this one. If you want pthreads, you've already
> got it. I would personally prefer to see more effort on separating the
> core language from the library. (It isn't clear whether something like
> std::uncaught_exception is implemented by the compiler vendor or
> the library vendor.) Next after that would be some portable way of
> navigating a directory tree.

You'd have to define what a directory is, first. So if you want POSIX,
you already gotit: readdir(3).

Regards,
Martin
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:

[...]

| ... I would personally prefer to see more effort on separating the
| core language from the library. (It isn't clear whether something like
| std::uncaught_exception is implemented by the compiler vendor or
| the library vendor.)

I was under the impression that it was a deliberate choice not to
define 'core language' and 'library' formally.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$rdb7kf$yfo$1@firewall.thermoteknix.co.uk>, "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>Zeisel Helmut wrote in message <38145573@webpc1.vai.co.at>...
>>
>>For the next version of the standard, however, I would wish that
>>there will be some minimal standardization of threads in C++.
>
>And security, and a GUI, and a component model? Even Bjarne's
>rice cooker might have trouble if we're not careful.
>

Everyone can add more points to the wish list,
but I hope we can get some consensus
which points are more important and which less.

>I would hold back on this one. If you want pthreads, you've already
>got it.

That is exactly the point. pthreads standardize the C part of C++,
but there is no standardization of the C++ part.
There is even no guarantee that one can use any part
of the non C part of C++ in threaded programs.
In practice, we are successfully using C++ in threaded programs
(this is why I think
it would not be so difficult to standardize it),
but we often do not know how portable our programs are
(strictly according to the standard,
they are not portable,
since the standard is silent about threads).

Helmut

--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <381414EC.6213@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> Steve Clamage wrote:
>
> > The problem is that there are so many incompatible thread
> > models to choose from, and each model has advantages and
> > disadvantages.
>
> Could you give me pointers ? ('cause I know only
> one thread model)
>

I know two thread models: POSIX or pthreads, and WIN32 threads.
I do not know which other exist, but AFAIK these two thread
models are currently the most important ones.

Helmut


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38145573@webpc1.vai.co.at> zeisel@vai.co.at writes:
>In article <7usftf$8r6$1@panix3.panix.com>, comeau@panix.com (Greg Comeau) writes:
>>In article <38102576@webpc1.vai.co.at> zeisel@vai.co.at writes:
>>>So the good news is that the members of the C++ committee accept their
>>>responsibility.
>>
>>The most direct cost (just for the meetings) of the Standard has been
>>thousands of hours and millions of dollars spent.  The indirect cost
>>is magnitudes that.  So, yes, they do, quite seriously.
>
>My intent was not to criticize the C++ committee in any way.
>I just wanted to say that I am happy that the C++ committe
>did not say that POSIX or someone else should do the
>work of standardization of threads in ISO C++.

The committee has not "said" anything either way.
Members do know that it's always a topic though.

>>FWIW, the committee has been talking about aspects of this since
>>its inception.  And many papers were written about it (both generally
>>and about the SL).  But as Steve says, if something like this needs
>>to be written in stone, as general purpose and for all to use portably
>>etc, then it need due focused consideration.  That this has not occurred
>>exhibits that it's needed the time it has taken so far.
>
>I got the impression that threads were excluded from the
>current version of the C++ standard because there were
>many more important things to standardize.

Yes and no.  Yes, the committee did work on many things.  So, as usual,
with a big project, priorities and deadlines are a reality.
But no, nobody (or the group as a whole) ever said
"threads are unimportant so let's leave them be."

>For the next version of the standard, however, I would wish that
>there will be some minimal standardization of threads in C++.
>If it really is so difficult to find a "univesral thread model",
>I even would be satisfied if this standardization
>is done for a single thread model, say POSIX or WIN32 threads.
>Hopefully it will not be too difficult to generalize
>this special solution to other thread models.

But this is one part of the problem.  That is, you mention wishes,
satisfactions, and hopes above, whereas somebody else mentions other
ones.

I suspect a single specific model like POSIX or WIN32 will never be accepted.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:

> That will depend on whether suitable definitions can be
> found that will satisfy everyone.  I don't forsee getting
> agreement on what thread model should be used.

My problem is that I don't know the arguments against
the thread-model.

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38102576@webpc1.vai.co.at> zeisel@vai.co.at writes:
>In article <7uokt6$oac$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve Clamage) writes:
>>zeisel@vai.co.at (Zeisel Helmut) writes:
>>
>>>Who is responsible for standardizing
>>>the behavior of C++ with respect to threads?
>>
>>The C++ committee.
>>
>>>Will this be done for a future version of ISO C++?
>>
>>That will depend on whether suitable definitions can be
>>found that will satisfy everyone.  I don't forsee getting
>>agreement on what thread model should be used.
>>
>>It took 5 years to settle on a definition for auto_ptr, and
>>some people still don't like it. I don't think multi-threading
>>issues are simpler than auto_ptr.
>>
>>The point is not that committee members are contentious.  The
>>point is that getting agreement on the One True Design for
>>anything is difficult.
>>
>
>So the good news is that the members of the C++ committee accept their
>responsibility.

The most direct cost (just for the meetings) of the Standard has been
thousands of hours and millions of dollars spent.  The indirect cost
is magnitudes that.  So, yes, they do, quite seriously.

>I understand that it is really difficult to obtain a
>good specification for a complete "Standard Thread Library".
>
>There were, however, a few articles in C++ report
>several months ago discussing thread safety of the STL
>and I got the impression that it is not so
>difficult to find an accepted definition
>what "thread safe" should mean for STL containers,
>so I think it should not be too difficult to specify
>for all the other libraries like streams and strings
>and global objects like "cout",
>what "thread safe" should mean.
>These definitions are essential
>to allow writing of portable multi threaded
>programs in C++.
>
>Clearly it would be much more work to define
>a standard C++ interface for creating und using threads
>independent from the respective thread model
>(although, AFAIK such libs exist already),
>but this is not so important as
>a suitable definition of "thread safe" for the existing libs.

FWIW, the committee has been talking about aspects of this since
its inception.  And many papers were written about it (both generally
and about the SL).  But as Steve says, if something like this needs
to be written in stone, as general purpose and for all to use portably
etc, then it need due focused consideration.  That this has not occurred
exhibits that it's needed the time it has taken so far.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

>Steve Clamage wrote:

>> That will depend on whether suitable definitions can be
>> found that will satisfy everyone.  I don't forsee getting
>> agreement on what thread model should be used.

>My problem is that I don't know the arguments against
>the thread-model.

The problem is that there are so many incompatible thread
models to choose from, and each model has advantages and
disadvantages.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Steve Clamage wrote:
>
> > That will depend on whether suitable definitions can be
> > found that will satisfy everyone.  I don't forsee getting
> > agreement on what thread model should be used.
>
> My problem is that I don't know the arguments against
> the thread-model.

Which one?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <380eefff@webpc1.vai.co.at> zeisel@vai.co.at writes:
>Who is responsible for standardizing
>the behavior of C++ with respect to threads?

If you mean, who handles C++ extensions, that would be the ISO C++ committee
assuing we're talking about modifying ISO C++.

>Will this be done for a future version of ISO C++?

Nobody knows.

>Or is there a POSIX group working on that?

I suppose they could do some work on it it they wanted,
but don't know that that will be occurring.

>Or is everbody wating for someone else to do the work?

Not necessarily.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

zeisel@vai.co.at (Zeisel Helmut) writes:

>Who is responsible for standardizing
>the behavior of C++ with respect to threads?

The C++ committee.

>Will this be done for a future version of ISO C++?

That will depend on whether suitable definitions can be
found that will satisfy everyone.  I don't forsee getting
agreement on what thread model should be used.

It took 5 years to settle on a definition for auto_ptr, and
some people still don't like it. I don't think multi-threading
issues are simpler than auto_ptr.

The point is not that committee members are contentious.  The
point is that getting agreement on the One True Design for
anything is difficult.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7uokt6$oac$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve Clamage) writes:
>zeisel@vai.co.at (Zeisel Helmut) writes:
>
>>Who is responsible for standardizing
>>the behavior of C++ with respect to threads?
>
>The C++ committee.
>
>>Will this be done for a future version of ISO C++?
>
>That will depend on whether suitable definitions can be
>found that will satisfy everyone.  I don't forsee getting
>agreement on what thread model should be used.
>
>It took 5 years to settle on a definition for auto_ptr, and
>some people still don't like it. I don't think multi-threading
>issues are simpler than auto_ptr.
>
>The point is not that committee members are contentious.  The
>point is that getting agreement on the One True Design for
>anything is difficult.
>

So the good news is that the members of the C++ committee accept their
responsibility.

I understand that it is really difficult to obtain a
good specification for a complete "Standard Thread Library".

There were, however, a few articles in C++ report
several months ago discussing thread safety of the STL
and I got the impression that it is not so
difficult to find an accepted definition
what "thread safe" should mean for STL containers,
so I think it should not be too difficult to specify
for all the other libraries like streams and strings
and global objects like "cout",
what "thread safe" should mean.
These definitions are essential
to allow writing of portable multi threaded
programs in C++.

Clearly it would be much more work to define
a standard C++ interface for creating und using threads
independent from the respective thread model
(although, AFAIK such libs exist already),
but this is not so important as
a suitable definition of "thread safe" for the existing libs.

Helmut



--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Who is responsible for standardizing
the behavior of C++ with respect to threads?

Will this be done for a future version of ISO C++?
Or is there a POSIX group working on that?
Or is everbody wating for someone else to do the work?

Helmut

--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]