AllanW@my-dejanews.com wrote:
>
> In article <362FCC2B.4FD178A@ix.netcom.com>,
>   "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> >
> > An exception handling mechanism designed for a
> > single-threaded environment is _guaranteed_ to fail if used in a
> > multi-threaded environment.
>
> Can you quote that guarantee? I can't find anything definitive,
> one way or the other.

I didn't mean that the standard guarantees it; I meant that reality
guarantees it. The most common implementation of exception handling
involves the use of a stack-pointer-like variable which records the
location on the stack of the most recent stack frame that has anything
to do with exception handling. It is used precisely to find "the handler
whose try block was most recently entered ... and not yet exited."
However, if this technique is blindly used in a multi-threaded
environment, it will do exactly what that clause describes, without the
phrase "by the thread of control", and possibly invoke some other
thread's exception handler.

--

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

In article <362905E3.86C4C56D@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> I have yet to hear an explanation of what "thread" refers to in this
> phrase, if not the thing that there are multiples of in a multi-threaded
> environment. If the standard isn't implying that multi-threaded versions
> of C++ must take threading into account in their implementation of
> exception handling, then I can't imagine what those words are doing in
> there. If you can, please give me an alternative reading that makes
> logical sense, and says something useful within the context of a
> standard.

> > > Al Stevens wrote:
> > > > The Microsoft Press Computer Dictionary, 1991 says,
> > > >
> > > > "thread - In programming, a process that is part of a
> > > > larger process or program."
> > > >
> > > > That's general enough to cover anything from an inline
> > > > function to a spawned program.
> > > >
> > > > "multithreading - The running of several processes in
> > > > rapid sequence (multitasking) within a single program."
> > > >
> > > > So, if you accept this tome as an authority, the standard's
> > > > use of the word thread does not seem to imply support for
> > > > multithreading.

> > "James Russell Kuyper Jr." <kuyper@wizard.net> wrote:
> > > That definition identifies multi-threading with multi-tasking. I've
> > > worked on systems where tasks and thread were very different things,
> > > with 1 or more threads per task. I'm not saying that the definition is
> > > wrong, merely that it is system specific. You shouldn't read too much
> > > into the C++ standard based upon these definitions (or any other
> > > definitions not normatively referenced by the standard itself).

> AllanW@my-dejanews.com wrote:
> > Sorry, but Al Stevens was not guilty of being system-specific -- you
> > were.

James Kuyper <kuyper@wizard.net> wrote:
> I described a system where his definition didn't make sense - that
> proves that his definition isn't a good general purpose definition.

> > > worked on systems where tasks and thread were very different things,
> >             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Your system defines a strict relationship between tasks and
> > threads, but this doesn't mean that all systems must do so.

> I wasn't suggesting that they should. I was merely pointing out that the
> Microsoft definition was not necessarily a good one to use for other
> systems. In particular, it's not a good one to use for understanding the
> meaning of the C++ standard.

I disagree. I think Microsoft did an admirable job of *NOT* being
system-specific in their definitions, especially considering the
fact that these two terms have *VERY* specific meaning in their
own operating systems.  (FWIW, those meanings extend these
definitions without conflicting in any way).

> > Refer to the definition that Al Stevens posted above. That definition
> > for "multi-threading" references the definition of "multi-tasking",
> > but then goes on to add a qualifier. In general, then, multiple tasks
> > may run multiple programs, while multiple threads are part of the same
> > program.

> If that was the intent, then the definition was incorrectly worded;

Oh?

> it says that multi-threading is a qualified kind of multi-tasking,

I would agree with that. Qualified because they all run as part of
the same program.

> whereas from your explanation, multi-threading and multi-tasking are
> non-overlapping concepts.

I don't believe I said that.

In any case, we wanted a definition of "thread" which did *not*
involve "multiple threads." I believe you have one hear. Multiple
threads are possible, but not at all supported by the C++ standard,
_not_even_with_respect_to_exception_handling_, despite the usage
of the phrase "thread of control" exactly once in that section
(only) of the standard.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <362FCC2B.4FD178A@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
>
> AllanW@my-dejanews.com wrote:
> >
> > I suggested earlier that "thread of control" in this context might
> > mean "logic path" -- in other words, the flow of logic from funcA()
> > to funcB() to funcC() and eventually back to funcA().
>
> I'm not saying that the computer world doesn't have any alternative
> meaning for "thread"; I'm saying that I can't think of any alternative
> meaning that makes sense in the context of the standard, where it says:
>
>   When  an  exception  is  thrown, control is transferred to the nearest
>   handler with a matching type (_except.handle_);  "nearest"  means  the
>   handler  whose  try  block  was most recently entered by the thread of
>   control and not yet exited.
>
> If a "thread" is nothing more than a logic path, or a control flow, or a
> data flow, then those words are superfluous.

And this is the only case where you've found superfluous words
in the standard?

> If, however, a "thread" is
> that thing of which there are multiples of in a multi-threaded
> environment, then the meaning is clear, and the reason those words are
> important is plain.

I'd like to believe that. I would like to take that one step
further; if a compiler claims to support multiple threads and
also support the C++ standard, then it should be required to
support them both at the same time.

But I don't think that the standard supports such a strong
claim, even with respect to exceptions in a multiple-threading
environment. If someone on the C++ committee who worked on that
passage would like to set me straight, I'm all ears.

(Well, all eyes -- after all, I can read your response but
I can't hear it...  sorry if that was a bad analogy...
*sigh* it's been a long week...)

> An exception handling mechanism designed for a
> single-threaded environment is _guaranteed_ to fail if used in a
> multi-threaded environment.

Can you quote that guarantee? I can't find anything definitive,
one way or the other.

> Is this horse dead yet?

The horse is on the last lap, limping badly but still moving.
The man from the glue factory is getting bored. (Poor little
horsie, I know how you feel.)

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

AllanW@my-dejanews.com wrote:
>
> In article <362905E3.86C4C56D@ix.netcom.com>,
>   "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
....
> > > > Al Stevens wrote:
> > > > > The Microsoft Press Computer Dictionary, 1991 says,
> > > > >
> > > > > "thread - In programming, a process that is part of a
> > > > > larger process or program."
> > > > >
> > > > > That's general enough to cover anything from an inline
> > > > > function to a spawned program.
> > > > >
> > > > > "multithreading - The running of several processes in
> > > > > rapid sequence (multitasking) within a single program."
> > > > >
> > > > > So, if you accept this tome as an authority, the standard's
> > > > > use of the word thread does not seem to imply support for
> > > > > multithreading.
>
> > > "James Russell Kuyper Jr." <kuyper@wizard.net> wrote:
> > > > That definition identifies multi-threading with multi-tasking. I've
> > > > worked on systems where tasks and thread were very different things,
> > > > with 1 or more threads per task. I'm not saying that the definition is
> > > > wrong, merely that it is system specific. You shouldn't read too much
> > > > into the C++ standard based upon these definitions (or any other
> > > > definitions not normatively referenced by the standard itself).
>
> > AllanW@my-dejanews.com wrote:
> > > Sorry, but Al Stevens was not guilty of being system-specific -- you
> > > were.
>
> James Kuyper <kuyper@wizard.net> wrote:
> > I described a system where his definition didn't make sense - that
> > proves that his definition isn't a good general purpose definition.
>
> > > > worked on systems where tasks and thread were very different things,
> > >             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > Your system defines a strict relationship between tasks and
> > > threads, but this doesn't mean that all systems must do so.
>
> > I wasn't suggesting that they should. I was merely pointing out that the
> > Microsoft definition was not necessarily a good one to use for other
> > systems. In particular, it's not a good one to use for understanding the
> > meaning of the C++ standard.
>
> I disagree. I think Microsoft did an admirable job of *NOT* being
> system-specific in their definitions, especially considering the
> fact that these two terms have *VERY* specific meaning in their
> own operating systems.  (FWIW, those meanings extend these
> definitions without conflicting in any way).
>
> > > Refer to the definition that Al Stevens posted above. That definition
> > > for "multi-threading" references the definition of "multi-tasking",
> > > but then goes on to add a qualifier. In general, then, multiple tasks
> > > may run multiple programs, while multiple threads are part of the same
> > > program.
>
> > If that was the intent, then the definition was incorrectly worded;
>
> Oh?
>
> > it says that multi-threading is a qualified kind of multi-tasking,
>
> I would agree with that. Qualified because they all run as part of
> the same program.
>
> > whereas from your explanation, multi-threading and multi-tasking are
> > non-overlapping concepts.
>
> I don't believe I said that.

I thought from your explanation that you took the Microsoft definition
to be applicable to the system I was describing. I thought that your
explanation made that applicability plausible (whereas I though it was
not plausible from the words of that definition itself). On that system,
multi-tasking is having two or more programs time-sharing a single set
of system resources; multi-threading is running multiple threads of code
within a single program, with context switching being under the
program's control. While there is obviously a close relationship between
those concepts, neither one is a special case of the other.

> In any case, we wanted a definition of "thread" which did *not*
> involve "multiple threads." I believe you have one hear. Multiple
> threads are possible, but not at all supported by the C++ standard,
> _not_even_with_respect_to_exception_handling_, despite the usage
> of the phrase "thread of control" exactly once in that section
> (only) of the standard.

I believe quite strongly that the "thread of control" carries some
meaning in this context that has nothing to do with multi-threaded code.
However, I don't think quoting the Microsoft definition is very
relevant.
---
[ 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              ]

AllanW@my-dejanews.com wrote:
>
> In article <362FCC2B.4FD178A@ix.netcom.com>,
>   "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> >
> > AllanW@my-dejanews.com wrote:
> > >
> > > I suggested earlier that "thread of control" in this context might
> > > mean "logic path" -- in other words, the flow of logic from funcA()
> > > to funcB() to funcC() and eventually back to funcA().
> >
> > I'm not saying that the computer world doesn't have any alternative
> > meaning for "thread"; I'm saying that I can't think of any alternative
> > meaning that makes sense in the context of the standard, where it says:
> >
> >   When  an  exception  is  thrown, control is transferred to the nearest
> >   handler with a matching type (_except.handle_);  "nearest"  means  the
> >   handler  whose  try  block  was most recently entered by the thread of
> >   control and not yet exited.
> >
> > If a "thread" is nothing more than a logic path, or a control flow, or a
> > data flow, then those words are superfluous.
>
> And this is the only case where you've found superfluous words
> in the standard?
>
> > If, however, a "thread" is
> > that thing of which there are multiples of in a multi-threaded
> > environment, then the meaning is clear, and the reason those words are
> > important is plain.
>
> I'd like to believe that. I would like to take that one step
> further; if a compiler claims to support multiple threads and
> also support the C++ standard, then it should be required to
> support them both at the same time.

I think the better place would be to put this into a general
definition of "multi-threading support". IMHO a good definition
of an implementation supporting MT is:

There can be more than one thread, and two threads which do not
access the same objects nor explicitly call thread-related
functions don't interfere with each other.

This automatically includes thread-safe exceptions (for every
language that supports exceptions) and thread-safe standard
libraries. The main advantage is that the definition is
language-independent.

[...]

>
> > An exception handling mechanism designed for a
> > single-threaded environment is _guaranteed_ to fail if used in a
> > multi-threaded environment.
>
> Can you quote that guarantee? I can't find anything definitive,
> one way or the other.

I think he didn't say the standard guarantees it, but he wants to say
that MT exception handling is so fundamentally different from ST-EH
that you can be sure that an EH implementation designed for ST won't
work on an MT environment.

However, I can imagine that this need not be true either - the
mechanisms needed to allow nested exceptions (a feature demanded
by the standard) might lead to MT-safe EH. Note that I say "might"
- if the implementor decides to use a global stack-like structure,
it will not be thread safe at all.
BTW, making EH threadsafe should be quite simple: Aquire a lock
at throw, and release it after the exception has been handled
completely (this means that all catch handlers have finished,
therefore a throw inside a catch should obviously not lock,
since the mutex is already locked).
I'm sure there are better ways for thread-safe EH, though.

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

"Bill Wade" <bill.wade@stoner.com> writes:

|>  >    static vector< int >v ;
|>  >    {
|>  >        Mutex               lock( someLock ) ;
|>  >        v[ 0 ] = 1 ;
|>  >    }
|>  >
|>  >Because v is not volatile, the compiler is free to move the actual write
|>  >out of the locked scope.  But declaring v volatile doesn't work for two
|>  >reasons:
|>
|>  Why not declare 'lock' to be volatile?  If the compiler can't see into its
|>  'structors, or if they access any of its data, the assignment will have to
|>  happen in scope.  Or am I missing something?

Declaring lock to be volatile doesn't have any effect on what the
compiler may do with regards to v.  For that matter, declaring v to be
volatile doesn't have any effect on what the compiler may do with the
reference returned by the expression v[0].  Formally, the only way to be
sure that v[0] is actually assigned before lock goes out of scope is for
vector<int>::operator[] to return a volatile reference.  Which is not
permitted by the standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


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

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  jkanze@otelo.ibmmail.com wrote:
|>
|>  > The problem is linked with the notion of observable behavior.
|>  > Consider the following code (where Mutex is a class which locks an
|>  > object in its constructor, and frees the lock in its destructor):
|>  >
|>  >     static vector< int >v ;
|>  >     {
|>  >         Mutex lock( someLock ) ;
|>  >         v[ 0 ] = 1 ;
|>  >     }
|>  >
|>  > Because v is not volatile, the compiler is free to move the actual
|>  > write out of the locked scope.  But declaring v volatile doesn't work
|>  > for two reasons:
|>  >
|>  > 1. The data actually modified isn't v, but something v points to, and
|>  > that something isn't declared volatile.
|>  >
|>  > 2. The function operator[] is NOT volatile, and thus, cannot be called
|>  > on a volatile object.
|>
|>  If the compiler can't see the definition of lock(), then it can't know
|>  that lock won't modify v, as you mentioned. If it can see inside lock(),
|>  ultimately, it will come either to a system call that it can't see, or
|>  it will come to some operation on a volatile something-or-other. In
|>  either case, it will know it can't rearrange the top two statements. I
|>  suppose if it knows that lock is in a scope that can't see v, because
|>  the latter is static, then it could legally claim the right to do the
|>  rearrangement. However, at that point, I'd regard the compiler's
|>  optimization capability as a danger to be wary of, not a feature to be
|>  thankful for.

Yes and no.  I've already used a compiler (on a PC) that deferred all
writes to the latest possible minute, on the grounds that it might use,
or even modify the variable, before the write.  (This is a cheap
heuristic; most of today's compilers will do enough flow analysis to
only defer the write if they actually do modify the variable later.)  Of
course, in this compiler, any function call triggered all of the writes,
because the compiler made no assumptions about what the function might
access.  But I've also used a compiler which maintained a list of system
request functions, and "knew" that these functions didn't access any of
the user's variables that weren't passed it as an argument.  Put the two
together...

In fact, of course, any compiler optimising to this level today will
know about lock, and what it implies, and will inhibit code movement
beyond this point.  But this is comp.STD.c++; we argue about what
compilers may do, according to the standard, and not what they actually
do do.  (No real compiler is going to reformat your disk in case of
arithmetic overflow, either.)

|>  I come from the world of crappy PC compilers, that don't come close to
|>  attempting that sort of global optimization. What's more, in stepping
|>  through machine language code, I never find myself wishing I had a
|>  compiler that rearranged code across sequence points, let alone function
|>  calls. I can do that at the source level, if I want to. My idea of
|>  optimization means making good use of registers, and boiling all the
|>  gobs of code that are created by inline template functions down to their
|>  essentials. In other words, I want a compiler that can write assembly
|>  code 90% as well as I can, not one that plays really obscure tricks to
|>  beat me by 10%.

Well, boiling down all of the code created by inline template functions
almost always involves code movement across sequence points, since the
function call and return are both sequence points.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung



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

> Al Stevens wrote:
> > The Microsoft Press Computer Dictionary, 1991 says,
> >
> > "thread - In programming, a process that is part of a larger process or
> > program."
> >
> > That's general enough to cover anything from an inline function to a spawned
> > program.
> >
> > "multithreading - The running of several processes in rapid sequence
> > (multitasking) within a single program."
> >
> > So, if you accept this tome as an authority, the standard's use of the word
> > thread does not seem to imply support for multithreading.

In article <362BCC19.56BA8065@wizard.net>,
  "James Russell Kuyper Jr." <kuyper@wizard.net> wrote:
> That definition identifies multi-threading with multi-tasking. I've
> worked on systems where tasks and thread were very different things,
> with 1 or more threads per task. I'm not saying that the definition is
> wrong, merely that it is system specific. You shouldn't read too much
> into the C++ standard based upon these definitions (or any other
> definitions not normatively referenced by the standard itself).

Sorry, but Al Stevens was not guilty of being system-specific -- you
were.

> worked on systems where tasks and thread were very different things,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Your system defines a strict relationship between tasks and
threads, but this doesn't mean that all systems must do so.

Refer to the definition that Al Stevens posted above. That definition
for "multi-threading" references the definition of "multi-tasking",
but then goes on to add a qualifier. In general, then, multiple tasks
may run multiple programs, while multiple threads are part of the same
program.

Nor is this definition intended to explain all the nuances of threads
and tasks; it just defines them.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

J. Kanze wrote:
>
> Well, boiling down all of the code created by inline template
> functions almost always involves code movement across sequence points,
> since the function call and return are both sequence points.

But not necessarily _rearranging_ code across sequence points. What I
meant was, I never find myself wishing it would really do Y before X,
when X appeared before Y in the code. That sort of rearrangement isn't
generally necessary when boiling off all the inline template function
crud.

--

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

AllanW@my-dejanews.com wrote:
>
> > Al Stevens wrote:
> > > The Microsoft Press Computer Dictionary, 1991 says,
> > >
> > > "thread - In programming, a process that is part of a larger process or
> > > program."
> > >
> > > That's general enough to cover anything from an inline function to a spawned
> > > program.
> > >
> > > "multithreading - The running of several processes in rapid sequence
> > > (multitasking) within a single program."
> > >
> > > So, if you accept this tome as an authority, the standard's use of the word
> > > thread does not seem to imply support for multithreading.
>
> In article <362BCC19.56BA8065@wizard.net>,
>   "James Russell Kuyper Jr." <kuyper@wizard.net> wrote:
> > That definition identifies multi-threading with multi-tasking. I've
> > worked on systems where tasks and thread were very different things,
> > with 1 or more threads per task. I'm not saying that the definition is
> > wrong, merely that it is system specific. You shouldn't read too much
> > into the C++ standard based upon these definitions (or any other
> > definitions not normatively referenced by the standard itself).
>
> Sorry, but Al Stevens was not guilty of being system-specific -- you
> were.

I described a system where his definition didn't make sense - that
proves that his definition isn't a good general purpose definition.

> > worked on systems where tasks and thread were very different things,
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Your system defines a strict relationship between tasks and
> threads, but this doesn't mean that all systems must do so.

I wasn't suggesting that they should. I was merely pointing out that the
Microsoft definition was not necessarily a good one to use for other
systems. In particular, it's not a good one to use for understanding the
meaning of the C++ standard.

> Refer to the definition that Al Stevens posted above. That definition
> for "multi-threading" references the definition of "multi-tasking",
> but then goes on to add a qualifier. In general, then, multiple tasks
> may run multiple programs, while multiple threads are part of the same
> program.

If that was the intent, then the definition was incorrectly worded; it
says that multi-threading is a qualified kind of multi-tasking, whereas
from your explanation, multi-threading and multi-tasking are
non-overlapping concepts.
---
[ 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              ]

AllanW@my-dejanews.com wrote:
>
> I suggested earlier that "thread of control" in this context might
> mean "logic path" -- in other words, the flow of logic from funcA()
> to funcB() to funcC() and eventually back to funcA().

I'm not saying that the computer world doesn't have any alternative
meaning for "thread"; I'm saying that I can't think of any alternative
meaning that makes sense in the context of the standard, where it says:

  When  an  exception  is  thrown, control is transferred to the nearest
  handler with a matching type (_except.handle_);  "nearest"  means  the
  handler  whose  try  block  was most recently entered by the thread of
  control and not yet exited.

If a "thread" is nothing more than a logic path, or a control flow, or a
data flow, then those words are superfluous. If, however, a "thread" is
that thing of which there are multiples of in a multi-threaded
environment, then the meaning is clear, and the reason those words are
important is plain. An exception handling mechanism designed for a
single-threaded environment is _guaranteed_ to fail if used in a
multi-threaded environment.

Is this horse dead yet?

--

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

>> Sorry, but Al Stevens was not guilty of being system-specific -- you
>> were.
>
>I described a system where his definition didn't make sense - that
>proves that his definition isn't a good general purpose definition.


Hey, guys, it ain't my definition. It's Microsoft's. I threw it into the
fray for consideration as to whether the standard's use of the word "thread"
implies that a Standard C++ compiler shall support multithreading
programming environments. I like Stroustrup's quote in 1992: "I did my PhD
on concurrency issues, and I came out of Cambridge knowing 40 ways of
getting it wrong. 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              ]

jkanze@otelo.ibmmail.com wrote:
>
> The phrase doesn't make the slightest reference to a multi-threaded
> enviroment.  If you are in a multi-threaded environment, you are not
> using a strictly conforming C++ implementation, so anything goes.
> (According to the standard, I mean.  Most vendors are a little bit
> more reasonable about it.)

If a C++ compiler is sold for use in an environment that supports
threads, and it uses a single global variable to keep track of the last
exception context on the stack, the use of threads will cause the
exception handling mechanism to fail.

You would argue that because threads themselves are not part of the
standard, the compiler is allowed to do anything, as soon as threads are
used. But because they included that phrase "by the thread of control",
they're implying that the mere presence of multi-threading must not
break exception handling in that particular manner. Otherwise, what is
the purpose of that phrase?

Technically, I'd agree that the standard doesn't prohibit 1+1=3 once
threads are used, because it doesn't mention threads in defining
arithmetic. But it does make that one (rather weak) guarantee about
exception handling, which we should be able to rely on.

They probably limited their mention of threads to the section on
exceptions because exception handling is the one aspect of the
implementation that _must_ be redesigned when moving to a multi-threaded
environment. Everything else will work normally, within certain obvious
constraints.

They should probably also mention threads under errno, but they've left
the definition of that to the C standard, of which I don't have a copy.
However, they did at least mention that errno is a macro, which it is
precisely because of the needs of multi-threaded environments.

--

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

Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
> But because they included that phrase "by the thread of control",
>they're implying that the mere presence of multi-threading must not
>break exception handling in that particular manner. Otherwise, what is
>the purpose of that phrase?

The word "thread" is overloaded in computer science.  The sentence
in question has nothing to do with threads in the multi-thread
sense.  Repeating the contrary won't make it so.

There is no standard for implementation of multi-threaded C++
implementations.  You have no better standard than sound
engineering sense to persuade implementors to do the right
thing.  Appeals to this paragraph of the standard will (rightly)
fall on deaf ears.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

  jkanze@otelo.ibmmail.com wrote:
> Some recent discussion in fr.comp.lang.c++ has caused me to realize that
> you cannot implement a threadsafe standard library without some sort of
> compiler extension.  In fact, you simply cannot use the standard library
> in a multi-threaded environment without some sort of compiler extension.
>
> The problem is linked with the notion of observable behavior.  Consider
> the following code (where Mutex is a class which locks an object in its
> constructor, and frees the lock in its destructor):
>
>     static vector< int >v ;
>     {
>         Mutex lock( someLock ) ;
>         v[ 0 ] = 1 ;
>     }
>
> Because v is not volatile, the compiler is free to move the actual write
> out of the locked scope.  But declaring v volatile doesn't work for two
> reasons:
>
> 1. The data actually modified isn't v, but something v points to, and that
> something isn't declared volatile.
>
> 2. The function operator[] is NOT volatile, and thus, cannot be called on
> a volatile object.
>
> In fact, you are generally pretty safe, because the destructor of the Mutex
> must sooner or later resolve to a non-inline function call -- freeing the
> mutex is normally a system call -- and the compiler cannot "know" that
> this function doesn't access the variable, and so must ensure that its
> memory image corresponds to what the abstract machine requires.  (The
> only exception would be if the variable were an auto variable whose
> address had never been taken.  But such a variable cannot possibly be
> accessed from another thread anyway.)
>
> Still, it does bother me that my programs only work because of weaknesses
> in current optimization technology.

Don't say it that way. Say that if anyone ever came up with that
particular optimization, they would have quickly retracted it,
because it would break any code that used mutexes.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

Nathan Myers wrote:
>
> Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
> > But because they included that phrase "by the thread of control",
> >they're implying that the mere presence of multi-threading must not
> >break exception handling in that particular manner. Otherwise, what
> >is the purpose of that phrase?
>
> The word "thread" is overloaded in computer science.  The sentence
> in question has nothing to do with threads in the multi-thread
> sense.  Repeating the contrary won't make it so.

I have yet to hear an explanation of what "thread" refers to in this
phrase, if not the thing that there are multiples of in a multi-threaded
environment. If the standard isn't implying that multi-threaded versions
of C++ must take threading into account in their implementation of
exception handling, then I can't imagine what those words are doing in
there. If you can, please give me an alternative reading that makes
logical sense, and says something useful within the context of a
standard.

--

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

jkanze@otelo.ibmmail.com wrote:

> The problem is linked with the notion of observable behavior.
> Consider the following code (where Mutex is a class which locks an
> object in its constructor, and frees the lock in its destructor):
>
>     static vector< int >v ;
>     {
>         Mutex lock( someLock ) ;
>         v[ 0 ] = 1 ;
>     }
>
> Because v is not volatile, the compiler is free to move the actual
> write out of the locked scope.  But declaring v volatile doesn't work
> for two reasons:
>
> 1. The data actually modified isn't v, but something v points to, and
> that something isn't declared volatile.
>
> 2. The function operator[] is NOT volatile, and thus, cannot be called
> on a volatile object.

If the compiler can't see the definition of lock(), then it can't know
that lock won't modify v, as you mentioned. If it can see inside lock(),
ultimately, it will come either to a system call that it can't see, or
it will come to some operation on a volatile something-or-other. In
either case, it will know it can't rearrange the top two statements. I
suppose if it knows that lock is in a scope that can't see v, because
the latter is static, then it could legally claim the right to do the
rearrangement. However, at that point, I'd regard the compiler's
optimization capability as a danger to be wary of, not a feature to be
thankful for.

I come from the world of crappy PC compilers, that don't come close to
attempting that sort of global optimization. What's more, in stepping
through machine language code, I never find myself wishing I had a
compiler that rearranged code across sequence points, let alone function
calls. I can do that at the source level, if I want to. My idea of
optimization means making good use of registers, and boiling all the
gobs of code that are created by inline template functions down to their
essentials. In other words, I want a compiler that can write assembly
code 90% as well as I can, not one that plays really obscure tricks to
beat me by 10%.

--

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

Paul D. DeRocco wrote in message <362905E3.86C4C56D@ix.netcom.com>...
>
>Nathan Myers wrote:
>>
>> Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
>> > But because they included that phrase "by the thread of control",
>> >they're implying that the mere presence of multi-threading must not
>> >break exception handling in that particular manner. Otherwise, what
>> >is the purpose of that phrase?
>>
>> The word "thread" is overloaded in computer science.  The sentence
>> in question has nothing to do with threads in the multi-thread
>> sense.  Repeating the contrary won't make it so.
>
>I have yet to hear an explanation of what "thread" refers to in this
>phrase, if not the thing that there are multiples of in a multi-threaded
>environment. If the standard isn't implying that multi-threaded versions
>of C++ must take threading into account in their implementation of
>exception handling, then I can't imagine what those words are doing in
>there. If you can, please give me an alternative reading that makes
>logical sense, and says something useful within the context of a
>standard.

The C++ Standard itself doesn't give any hints about the intended
meaning (grep confirms that this is the only appearance of the word
"thread" in the entire Standard, or at least in CD2). However, one of
the normative references is _ISO/IEC 2382 Dictionary for Information
Processing Systems_. Has anyone thought of looking it up in there? (I
don't have a copy.)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
      "Screw up your courage. You've screwed up everything else."
---
[ 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              ]

The Microsoft Press Computer Dictionary, 1991 says,

"thread - In programming, a process that is part of a larger process or
program."

That's general enough to cover anything from an inline function to a spawned
program.

"multithreading - The running of several processes in rapid sequence
(multitasking) within a single program."

So, if you accept this tome as an authority, the standard's use of the word
thread does not seem to imply support for multithreading.



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

> jkanze@otelo.ibmmail.com wrote:
> > The problem is linked with the notion of observable behavior.
> > Consider the following code (where Mutex is a class which locks an
> > object in its constructor, and frees the lock in its destructor):
> >
> >     static vector< int >v ;
> >     {
> >         Mutex lock( someLock ) ;
> >         v[ 0 ] = 1 ;
> >     }
> >
> > Because v is not volatile, the compiler is free to move the actual
> > write out of the locked scope.  But declaring v volatile doesn't work
> > for two reasons:
> >
> > 1. The data actually modified isn't v, but something v points to, and
> > that something isn't declared volatile.
> >
> > 2. The function operator[] is NOT volatile, and thus, cannot be called
> > on a volatile object.

In article <3629087A.D1CDC166@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> If the compiler can't see the definition of lock(), then it can't know
> that lock won't modify v, as you mentioned. If it can see inside lock(),
> ultimately, it will come either to a system call that it can't see, or
> it will come to some operation on a volatile something-or-other. In
> either case, it will know it can't rearrange the top two statements.

I quite agree.

> I suppose if it knows that lock is in a scope that can't see v, because
> the latter is static, then it could legally claim the right to do the
> rearrangement. However, at that point, I'd regard the compiler's
> optimization capability as a danger to be wary of, not a feature to be
> thankful for.

Well, if it can see that lock isn't in that scope, but can't analyze
the contents of lock, then it can't assume that lock doesn't call some
other function, and that function *IS* in a scope that can see v.

What if it *CAN* see into lock? Perhaps it can recognize the system
call to locking functions and deal with that appropriately!

> I come from the world of crappy PC compilers, that don't come close to
> attempting that sort of global optimization. What's more, in stepping
> through machine language code, I never find myself wishing I had a
yada yada yada
> essentials. In other words, I want a compiler that can write assembly
> code 90% as well as I can, not one that plays really obscure tricks to
> beat me by 10%.

You know, I think anyone with enough energy can find something to
complain about that does exist. Why go off complaining about things
that probably don't exist, but might, and if they do we sure don't
like them, and somebody ought to be ashamed of themselves, which is
probably why they're not even owning up to doing it, unless of course
these things really don't exist in the first place, which they
probably don't, but they sure might, and we *still* don't like them?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

Al Stevens wrote:
>
> The Microsoft Press Computer Dictionary, 1991 says,
>
> "thread - In programming, a process that is part of a larger process or
> program."
>
> That's general enough to cover anything from an inline function to a spawned
> program.
>
> "multithreading - The running of several processes in rapid sequence
> (multitasking) within a single program."
>
> So, if you accept this tome as an authority, the standard's use of the word
> thread does not seem to imply support for multithreading.

That definition identifies multi-threading with multi-tasking. I've
worked on systems where tasks and thread were very different things,
with 1 or more threads per task. I'm not saying that the definition is
wrong, merely that it is system specific. You shouldn't read too much
into the C++ standard based upon these definitions (or any other
definitions not normatively referenced by the standard itself).



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
> > > But because they included that phrase "by the thread of control",
> > >they're implying that the mere presence of multi-threading must not
> > >break exception handling in that particular manner. Otherwise, what
> > >is the purpose of that phrase?

> Nathan Myers wrote:
> > The word "thread" is overloaded in computer science.  The sentence
> > in question has nothing to do with threads in the multi-thread
> > sense.  Repeating the contrary won't make it so.

In article <362905E3.86C4C56D@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> I have yet to hear an explanation of what "thread" refers to in this
> phrase, if not the thing that there are multiples of in a multi-threaded
> environment. If the standard isn't implying that multi-threaded versions
> of C++ must take threading into account in their implementation of
> exception handling, then I can't imagine what those words are doing in
> there. If you can, please give me an alternative reading that makes
> logical sense, and says something useful within the context of a
> standard.

I suggested earlier that "thread of control" in this context might
mean "logic path" -- in other words, the flow of logic from funcA()
to funcB() to funcC() and eventually back to funcA().

To support my claim, I quote selected passages from FOLDOC (the Free
On-Line Dictionary Of Computing), from page
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?threaded+code :

    THREADED CODE

    <programming> A technique for implementing virtual machine
    interpreters, introduced by J.R. Bell in 1973, where each
    op-code in the virtual machine instruction set is the address
    of some (lower level) code to perform the required operation.
    This kind of virtual machine can be implemented efficiently in
    machine code on most processors by simply performing an
    indirect jump to the address which is the next instruction.

    ["James R. Bell", "Threaded Code", CACM, 1973, 16, 6, pp 370-372].

    ["An Architectural Trail to Threaded Code Systems", Kogge, P. M.,
    IEEE Computer, March 1982].

See also
http://www.complang.tuwien.ac.at/forth/threaded-code.html#portability
for more on "threads" as they relate to the Forth language.

This definition isn't exactly what I was saying. But note that the
only "thread" in this context is control flow; in any case, there
is certainly no reference to "multiple threads" here, just as there
are none (elsewhere, at least) in the C++ standard.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

>    static vector< int >v ;
>    {
>        Mutex               lock( someLock ) ;
>        v[ 0 ] = 1 ;
>    }
>
>Because v is not volatile, the compiler is free to move the actual write
>out of the locked scope.  But declaring v volatile doesn't work for two
>reasons:

Why not declare 'lock' to be volatile?  If the compiler can't see into its
'structors, or if they access any of its data, the assignment will have to
happen in scope.  Or am I missing something?
---
[ 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              ]

Ross Smith<ross.s@ihug.co.nz> wrote:
>Paul D. DeRocco wrote in message <362905E3.86C4C56D@ix.netcom.com>...
>>Nathan Myers wrote:
>>>
>>> Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
>>> > But because they included that phrase "by the thread of control",
>>> >they're implying that the mere presence of multi-threading must not
>>> >break exception handling in that particular manner. Otherwise, what
>>> >is the purpose of that phrase?
>>>
>>> The word "thread" is overloaded in computer science.  The sentence
>>> in question has nothing to do with threads in the multi-thread
>>> sense.  Repeating the contrary won't make it so.
>>
>>I have yet to hear an explanation of what "thread" refers to in this
>>phrase, if not the thing that there are multiples of in a multi-threaded
>>environment. If the standard isn't implying that multi-threaded versions
>>of C++ must take threading into account in their implementation of
>>exception handling, then I can't imagine what those words are doing in
>>there. If you can, please give me an alternative reading that makes
>>logical sense, and says something useful within the context of a
>>standard.
>
>The C++ Standard itself doesn't give any hints about the intended
>meaning (grep confirms that this is the only appearance of the word
>"thread" in the entire Standard, or at least in CD2). However, one of
>the normative references is _ISO/IEC 2382 Dictionary for Information
>Processing Systems_. Has anyone thought of looking it up in there? (I
>don't have a copy.)

You won't get anything useful from 2382, because nobody was looking
at that when the paragraph was written.  The "thread of control" in
question referred to the sequence of tests and branches that led to
the point in question.

Can we please drop this thread now?  I don't want to report you to
Josee, and you *don't* want Josee mad at you.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  AllanW@my-dejanews.com wrote:
|>
|>  > Er -- I don't think so. I believe that "the thread of control" in this
|>  > case is being used as a synonym for "the control logic path".
|>
|>  [code snipped]
|>
|>  > I think that the awkward wording was intended to demonstrate that
|>  > the throw statement in this example throws to the indicated statement
|>  > in the catch block. We can't say
|>  >    When an exception is thrown, control is transferred to the catch
|>  >    statement for the current try block
|>  > because this throw isn't in a try block. We can't even say
|>  >    When an exception is thrown, control is transferred to the catch
|>  >    statement for the current try block, if any, otherwise control is
|>  >    transferred to the catch statement for the try block in the
|>  >    calling function
|>  > because in this case the calling function doesn't have a try block
|>  > either. We're left with
|>  > >   When an exception is thrown, control is transferred to the nearest
|>  > >   handler with a matching type; "nearest" means the handler whose
|>  > >   try block  was most recently entered by the thread of control and
|>  > >   not yet exited.
|>  > But again, IMO, this has nothing to do with the Computer Science
|>  > concept known as Multiple Threads.
|>
|>  Sure it does. In a non-multithreaded environment, they could have left
|>  out "by the thread of control" and written: "'nearest' means the handler
|>  whose try block was most recently entered and not yet exited."

They could have worded the paragraph a dozen different ways.  Never the
less, the choice of the expression "thread of control" doesn't imply the
least bit of support for multi-threading.  The expression "multiple
threads" derives from the more general concept of a thread of control;
it is a standard data processing concept.

|>  The only
|>  situation in which this temporal order can be violated is in a
|>  multi-threaded environment. The "thread" they are talking about is
|>  precisely the thing that there are multiples of in a multi-threading
|>  environment.

The thread they are talking about is the thing that there are multiples
of in a multi-threading environment.  I agree there.  But they are only
talking about one of them, and it takes more than one to have
multi-threading.

In a more general sense, a signal handler runs in a separate thread.
And the C standard is very precise as to what this means -- you can't do
anything but access a single basic type, sigatomic_t, and that only in
restricted ways.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


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

J. Kanze wrote:
>
> The thread they are talking about is the thing that there are
> multiples of in a multi-threading environment.  I agree there.  But
> they are only talking about one of them, and it takes more than one to
> have multi-threading.

True. My only point is that that phrase imposes a requirement that
exceptions work "right", even in a multi-threaded environment.
Therefore, the standard, while not supporting or requiring
multi-threading, recognizes its existence and acknowledges the need for
the language to work with it. It would be nice if this same minimal
recognition of threads was somehow worked into some of the library
specifications, to define some readily-achieved level of thread-safety.

--

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

In article <3622AA71.BB26E47A@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> J. Kanze wrote:
> >
> > The thread they are talking about is the thing that there are
> > multiples of in a multi-threading environment.  I agree there.  But
> > they are only talking about one of them, and it takes more than one to
> > have multi-threading.
>
> True. My only point is that that phrase imposes a requirement that
> exceptions work "right", even in a multi-threaded environment.

The phrase doesn't make the slightest reference to a multi-threaded
enviroment.  If you are in a multi-threaded environment, you are not
using a strictly conforming C++ implementation, so anything goes.
(According to the standard, I mean.  Most vendors are a little bit
more reasonable about it.)

> Therefore, the standard, while not supporting or requiring
> multi-threading, recognizes its existence and acknowledges the need for
> the language to work with it. It would be nice if this same minimal
> recognition of threads was somehow worked into some of the library
> specifications, to define some readily-achieved level of thread-safety.

Some recent discussion in fr.comp.lang.c++ has caused me to realize that
you cannot implement a threadsafe standard library without some sort of
compiler extension.  In fact, you simply cannot use the standard library
in a multi-threaded environment without some sort of compiler extension.

The problem is linked with the notion of observable behavior.  Consider
the following code (where Mutex is a class which locks an object in its
constructor, and frees the lock in its destructor):

    static vector< int >v ;
    {
        Mutex               lock( someLock ) ;
        v[ 0 ] = 1 ;
    }

Because v is not volatile, the compiler is free to move the actual write
out of the locked scope.  But declaring v volatile doesn't work for two
reasons:

1. The data actually modified isn't v, but something v points to, and that
something isn't declared volatile.

2. The function operator[] is NOT volatile, and thus, cannot be called on
a volatile object.

In fact, you are generally pretty safe, because the destructor of the Mutex
must sooner or later resolve to a non-inline function call -- freeing the
mutex is normally a system call -- and the compiler cannot "know" that
this function doesn't access the variable, and so must ensure that its
memory image corresponds to what the abstract machine requires.  (The
only exception would be if the variable were an auto variable whose
address had never been taken.  But such a variable cannot possibly be
accessed from another thread anyway.)

Still, it does bother me that my programs only work because of weaknesses
in current optimization technology.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

J. Kanze wrote:
>
> The ISO standard doesn't recognize threads, so obviously, can make no
> requirements with regards to thread safety.

It does "recognize" threads in at least one place. In 15.1
[except.throw] paragraph 2 it says,:

  When an exception is thrown, control is transferred to the nearest
  handler with a matching type; "nearest" means the handler whose try
  block  was most recently entered by the thread of control and not yet
  exited.

This implies that if an environment allows multiple threads, exception
handling must still work properly. In an analogous manner, it should
therefore be possible to define some level of thread-safety in the
standard library without actually adding threads to the standard.

--

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

Gilbert Chang <gchang@ccnet.com> wrote:
>
>> Do be sure to get the latest STL from SGI.  Note also that the STL
>> is only part of the standard library; the rest of libstdc++ is still
>> being worked on, and is not thread-safe by any definition.
>
>Hmm, I am a little disappointed.  Do you know when the rest of libstdc++
>would be at same thread-safety level as SGI's STL (3.1)?

Quicker if you help.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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 <361974DD.8B2CE042@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> J. Kanze wrote:
> >
> > The ISO standard doesn't recognize threads, so obviously, can make no
> > requirements with regards to thread safety.
>
> It does "recognize" threads in at least one place. In 15.1
> [except.throw] paragraph 2 it says,:
>
>   When an exception is thrown, control is transferred to the nearest
>   handler with a matching type; "nearest" means the handler whose try
>   block  was most recently entered by the thread of control and not yet
>   exited.
>
> This implies that if an environment allows multiple threads, exception
> handling must still work properly. In an analogous manner, it should
> therefore be possible to define some level of thread-safety in the
> standard library without actually adding threads to the standard.

Er -- I don't think so. I believe that "the thread of control" in this
case is being used as a synonym for "the control logic path".

    void func1() {
        try { // The try block
            func2();
        } catch (int i) { // The nearest handler
            // The statement that catches the thrown int
            std::cout << "Caught " << i << std::endl;
        }
    }
    void func2() {
        func3();
    }
    void func3() {
        throw 25;
    }
I think that the awkward wording was intended to demonstrate that
the throw statement in this example throws to the indicated statement
in the catch block. We can't say
   When an exception is thrown, control is transferred to the catch
   statement for the current try block
because this throw isn't in a try block. We can't even say
   When an exception is thrown, control is transferred to the catch
   statement for the current try block, if any, otherwise control is
   transferred to the catch statement for the try block in the
   calling function
because in this case the calling function doesn't have a try block
either. We're left with
>   When an exception is thrown, control is transferred to the nearest
>   handler with a matching type; "nearest" means the handler whose try
>   block  was most recently entered by the thread of control and not yet
>   exited.
But again, IMO, this has nothing to do with the Computer Science
concept known as Multiple Threads.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

AllanW@my-dejanews.com wrote:

> Er -- I don't think so. I believe that "the thread of control" in this
> case is being used as a synonym for "the control logic path".

[code snipped]

> I think that the awkward wording was intended to demonstrate that
> the throw statement in this example throws to the indicated statement
> in the catch block. We can't say
>    When an exception is thrown, control is transferred to the catch
>    statement for the current try block
> because this throw isn't in a try block. We can't even say
>    When an exception is thrown, control is transferred to the catch
>    statement for the current try block, if any, otherwise control is
>    transferred to the catch statement for the try block in the
>    calling function
> because in this case the calling function doesn't have a try block
> either. We're left with
> >   When an exception is thrown, control is transferred to the nearest
> >   handler with a matching type; "nearest" means the handler whose
> >   try block  was most recently entered by the thread of control and
> >   not yet exited.
> But again, IMO, this has nothing to do with the Computer Science
> concept known as Multiple Threads.

Sure it does. In a non-multithreaded environment, they could have left
out "by the thread of control" and written: "'nearest' means the handler
whose try block was most recently entered and not yet exited." The only
situation in which this temporal order can be violated is in a
multi-threaded environment. The "thread" they are talking about is
precisely the thing that there are multiples of in a multi-threading
environment.

--

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

Gilbert Chang <gchang@ccnet.com> wrote:
>P.J. Plauger wrote:
>> Gilbert Chang <gchang@ccnet.com> wrote :
>> > egcs is shipped with the SGI version of STL, isn't it?  The following is
>> > quoted from SGI's STL page I just found:
>> > .....
>> > Looks a very reasonable design to me.  So I suppose I am on the safe
>> > side if I use egcs1.1.
>>
>> For the STL part, perhaps, but not the entire library. There's far
>> more to the Standard C++ library than STL.
>
>Oops, I meant to ask if the entire standard library implementation
>is thread-safe.  Let me try again.  Anyone knows if the rest of std++
>of egcs is thread-safe (and in what sense)?

It's not, in any sense.  As I said, that's being worked on.
When the safe version is released, it will be safe in the same
sense as the STL.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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 <6utvkv$7eg$1@shell7.ba.best.com>,
  ncm@nospam.cantrip.org (Nathan Myers) wrote:
> Local static constructed variables, like
>
>   X& f() { X x; return x; }  // X::X() is a real function
>
> are also not currently thread-safe in Egcs either, nor indeed in
> most compilers that claim to be thread-safe.  You have to guard
> the initialization of these statics "manually".

Could you elaborate?

The code above has a problem because it's returning an auto X object
by reference -- the caller will have a reference to a deleted object.
Is that what you were referring to?

 [Moderator's note: Nathan Myers undoubtable meant
    X& f() { static X x; return x; }  // X::X() is a real function
      ^^^^^^   -moderator (fjh).]
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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 <6utvkv$7eg$1@shell7.ba.best.com>,
>   ncm@nospam.cantrip.org (Nathan Myers) wrote:
> >   X& f() { X x; return x; }  // X::X() is a real function

In article <6v0u15$s36$1@nnrp1.dejanews.com>, I wrote:
> The code above has a problem because it's returning an auto X object
> by reference -- the caller will have a reference to a deleted object.
> Is that what you were referring to?

and the moderator added:
>  [Moderator's note: Nathan Myers undoubtable meant
>     X& f() { static X x; return x; }  // X::X() is a real function

Yes, Mr. Myers said so in a different post, which I read about
five minutes after posting this.

Mr. Myers was talking about thread-unsafe code in compilers
that call themselves thread-safe. Note that there is no ANSI
or ISO definition of thread-safe, so I suppose that a compiler
vendor can use that label whenever they darn well feel like it.
But if the compiler doesn't protect "x" in the above code from
being constructed twice, then at least common sense would tell
us that the compiler's code is NOT thread-safe, right?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

AllanW@my-dejanews.com (AllanW@my-dejanews.com) wrote:
>Note that there is no ANSI
>or ISO definition of thread-safe

Until this point I was feeling very stupid; now I just feel slightly
stupid.

I have a general idea of what I think of when I hear "thread safe":
different program threads can access the same object without balling
things up.

Can anyone provide a brief but more clear definition?

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting 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              ]

In article <MPG.107f12f91941039898a1e2@news.concentric.net>,
brownsta@concentric.net (Stan Brown) wrote:

> AllanW@my-dejanews.com (AllanW@my-dejanews.com) wrote:
> >Note that there is no ANSI
> >or ISO definition of thread-safe
>
> Until this point I was feeling very stupid; now I just feel slightly
> stupid.
>
> I have a general idea of what I think of when I hear "thread safe":
> different program threads can access the same object without balling
> things up.
>
> Can anyone provide a brief but more clear definition?

I'll provide one, but it contradicts your feeling.  I'm quoting what
others have written, but it is also what I believe to be the best
definition:

Ignatchenko, Sergey: "STL Implementations and Thread Safety", C++ Report,
July-August 1998.

STL implementation is usually considered multithread safe if the following
conditions are met:

1. It is safe to simultaneously read and write accesses from different
threads to distinct containers.

2. It is safe to simultaneously read accesses from different threads to
the same container.

3.  It is not safe for different threads to simultaneously access the same
container when at least one thread writes to the container. The programmer
is responsible for using thread synchronization primitives (mutexex,
mutex-like objects, and so on) to avoid such situations.

There are many compelling arguments to support this definition.

-Howard
---
[ 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 <6v303u$lvp$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:


> > In article <6utvkv$7eg$1@shell7.ba.best.com>,
> >   ncm@nospam.cantrip.org (Nathan Myers) wrote:
> > >   X& f() { X x; return x; }  // X::X() is a real function

> In article <6v0u15$s36$1@nnrp1.dejanews.com>, I wrote:
> > The code above has a problem because it's returning an auto X object
> > by reference -- the caller will have a reference to a deleted object.
> > Is that what you were referring to?

> and the moderator added:
> >  [Moderator's note: Nathan Myers undoubtable meant
> >     X& f() { static X x; return x; }  // X::X() is a real function

> Yes, Mr. Myers said so in a different post, which I read about
> five minutes after posting this.

> Mr. Myers was talking about thread-unsafe code in compilers
> that call themselves thread-safe. Note that there is no ANSI
> or ISO definition of thread-safe, so I suppose that a compiler
> vendor can use that label whenever they darn well feel like it.
> But if the compiler doesn't protect "x" in the above code from
> being constructed twice, then at least common sense would tell
> us that the compiler's code is NOT thread-safe, right?

No. If you want your MT code to be portable, assume that function
static objects are not MT-safe. Instead you can use a global object
(or a class static) or use a  lock to initialize it.

- Saroj Mahaptra

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

Stan Brown<brownsta@concentric.net> wrote:
>AllanW@my-dejanews.com (AllanW@my-dejanews.com) wrote:
>>Note that there is no ANSI or ISO definition of thread-safe
>
>I have a general idea of what I think of when I hear "thread safe":
>different program threads can access the same object without balling
>things up.

No, that's what is sometimes referred to as "thread-hot".
It may be appropriate for high-level components.  A
thread-hot component is also called a "monitor" (cf. Hoare).

>Can anyone provide a brief but more clear definition?

The SGI web page goes into more detail, but the basic idea is that
a thread-safe library can be called safely by two different threads
as long as they are careful *not* to access the same object at the
same time.

In other words, given a thread-safe library I can say

  std::string s = "a";
  std::string t = s;

and then 's' can be operated on on by one thread, and 't' by another,
without need for them to co-operate, despite that the storage used
by 's' may be shared with 't'.  If both threads want to use 's', they
must use a lock.

Thread-safety makes it *possible* for you to write thread-safe code
of your own, but it does not relieve you of any responsibility
for locking visible objects you want to share.  In the case of
std::string, or operator new, sharing goes on "behind the scenes",
so you would have no way to lock the things they share.  They do
that job if they are thread-safe.  Managing access to visible objects
is your job.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Stan Brown <brownsta@concentric.net> wrote in article <MPG.107f12f91941039898a1e2@news.concentric.net>...
> I have a general idea of what I think of when I hear "thread safe":
> different program threads can access the same object without balling
> things up.
>
> Can anyone provide a brief but more clear definition?

No, yours is a delightful balance of brevity and colloquial piquancy. But
here is a less brief but more precise guideline for writing libraries for use
in thread-safe programs. It is the one promulgated by the folks at Silicon
Graphics, when describing their version of STL:

The same object can be read by two or more threads without conflict.
(No secret unprotected writes can occur.)

One thread can write an object and another thread can read a different
object of the same type without conflict. (No secret unprotected reads of
a class shared object can occur.)

The same object cannot be written by one thread and read or written by
another without conflict. (It's up to you to protect against obvious
conflicts.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



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

brownsta@concentric.net (Stan Brown) writes:

|>  AllanW@my-dejanews.com (AllanW@my-dejanews.com) wrote:
|>  >Note that there is no ANSI
|>  >or ISO definition of thread-safe
|>
|>  Until this point I was feeling very stupid; now I just feel slightly
|>  stupid.
|>
|>  I have a general idea of what I think of when I hear "thread safe":
|>  different program threads can access the same object without balling
|>  things up.
|>
|>  Can anyone provide a brief but more clear definition?

There isn't one.  Your definition is probably the most widespread, and
is certainly the most "obvious".  It is also not very practical; in
almost all cases where two threads are accessing the same object, the
level of granularity needed is higher than what the compiler can offer,
so the user needs to implement thread safety himself anyway.  And adding
the thread safety of this sort to the compiler generated code and/or the
library really slows things down enormously.

FWIW: Java through 1.1 implemented this "naive" thread safety in its
libraries.  And that, much more than garbage collection or the lack of
optimization implicite in a compile and go (JIT in newspeak) compiler,
has been the problem in every real case of insufficient performance I'm
aware of.  In 1.2, Java has changed this policy to conform to what
Nathan Meyrs, Matt Austin and others here are describing as the
desirable level of thread safety.

(As an interesting sidelight: I've started using Java intensively
recently, and I've discovered that writing portable Java is even more
difficult than writing portable C++, despite all the claims to the
contrary.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


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

brownsta@concentric.net (Stan Brown) wrote:

>Can anyone provide a brief but more clear definition?

Thanks to Hinnant, Plauger, and Myers for their replies. I think I
understand now.

I had previously taken it for granted that two threads could safely
*read* the same object, but I see I was overlooking the possibility of
those writes triggering secret reads (e.g. caching a computed result).

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting 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              ]

AllanW@my-dejanews.com writes:

|>  > In article <6utvkv$7eg$1@shell7.ba.best.com>,
|>  >   ncm@nospam.cantrip.org (Nathan Myers) wrote:
|>  > >   X& f() { X x; return x; }  // X::X() is a real function
|>
|>  In article <6v0u15$s36$1@nnrp1.dejanews.com>, I wrote:
|>  > The code above has a problem because it's returning an auto X object
|>  > by reference -- the caller will have a reference to a deleted object.
|>  > Is that what you were referring to?
|>
|>  and the moderator added:
|>  >  [Moderator's note: Nathan Myers undoubtable meant
|>  >     X& f() { static X x; return x; }  // X::X() is a real function
|>
|>  Yes, Mr. Myers said so in a different post, which I read about
|>  five minutes after posting this.
|>
|>  Mr. Myers was talking about thread-unsafe code in compilers
|>  that call themselves thread-safe. Note that there is no ANSI
|>  or ISO definition of thread-safe, so I suppose that a compiler
|>  vendor can use that label whenever they darn well feel like it.
|>  But if the compiler doesn't protect "x" in the above code from
|>  being constructed twice, then at least common sense would tell
|>  us that the compiler's code is NOT thread-safe, right?

The ISO standard doesn't recognize threads, so obviously, can make no
requirements with regards to thread safety.

Defining what the compiler should do in the preceding example is a bit
awkward anyway.  Normally, thread safety, at least the useful thread
safety, doesn't apply to accessing the same object within separate
threads, only to accessing different objects.  Realistically, thread
safety with regards to accessing the same object should be in the hands
of the user.  And all calls to this function will necessarily access the
same (static) object.  On the other hand, if the object is never
modified, the user certainly doesn't want to have to acquire a mutex
every time the function is called.

And then, there could be compilers which will allow putting the local
statics in thread specific memory; each thread has its own copy.

IMHO: putting the local statics in thread specific memory should not be
the default, although it is a nice option, under the control of a
compiler option or a pragma.  Other than that, the compiler shouldn't do
anything.  It is the users problem.  And typically, the only reasonable
solution involves a double lock, to avoid grabbing the mutex every time
the function is called.  (The main reason I don't think it the compilers
problem is that I'm not convinced that something as complicated as a
double lock should be hidden in the compiler generated code.  But I'm
very open to being convinced otherwise.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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              ]

Howard Hinnant (hinnant@_anti-spam_lightlink.com) wrote:
: 3.  It is not safe for different threads to simultaneously access the same
: container when at least one thread writes to the container. The programmer
: is responsible for using thread synchronization primitives (mutexex,
: mutex-like objects, and so on) to avoid such situations.

: There are many compelling arguments to support this definition.

Yes. Note that the static object construction case also being discussed
under this subject heading falls under this case. Hence the astute reader
will conclude there is a strong case to be made for the compiler and
runtime not ensuring mutual exclusion of construction of static
objects. (The counter argument perhaps is that the performance argument in
favor of the above quoted clause is not really present as its just the
constructor that is being protected. I'm not sure I believe that but I'll
withhold judgement until I've read the reference posted on how to implement
this.)

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

P.J. Plauger wrote:

> Gilbert Chang <gchang@ccnet.com> wrote in article <36107DCA.C44DAF05@ccnet.com>...
> > egcs is shipped with the SGI version of STL, isn't it?  The following is
> > quoted from SGI's STL page I just found:
> > .....
> > Looks a very reasonable design to me.  So I suppose I am on the safe side if
> > I use egcs1.1.
>
> For the STL part, perhaps, but not the entire library. There's far more to the
> Standard C++ library than STL.

Oops, I meant to ask if the entire standard library implementation is thread-safe.
Let me try again.  Anyone knows if the rest of std++ of egcs is thread-safe (an in
what sense)?

>
>
> > I think VC++5.0's STL has the same level of thread-safety if I apply the
> > fixes sugguested by Mr. Plauger.  Correct me if I am wrong.  Anybody knows
> > about VC++6.0?
>
> Apply the same fixes and it too is thread safe, in the same sense as SGI.

The entire standard library or only the STL part?
---
[ 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              ]

Gilbert Chang <gchang@ccnet.com> wrote:
>
>> The current libstdc++ that comes with g++ is not thread-safe.
>> In fact, the exception handling in g++-2.8.x is not, either,
>> so a conforming thread-safe library cannot be written for
>> g++-2.8.x.
>>
>> Egcs-1.1, its successor, comes with essentially the same library,
>> so it it not thread-safe yet.  However, the core language
>> implementation *is* thread-safe, and the library is being
>> rewritten, and will be thread-safe.
>
>I thought the exception handlings in both g++2.8.x and egcs1.1 were
>thread-safe.  Guess I have to use egcs1.1 if I want to be strict about
>thread safety.

Correct.  However, note also...
Local static constructed variables, like

  X& f() { X x; return x; }  // X::X() is a real function

are also not currently thread-safe in Egcs either, nor indeed in
most compilers that claim to be thread-safe.  You have to guard
the initialization of these statics "manually".

>> >If not, how unsafe are they?  It's quite easy to cope with the situation
>> >where invoking methods on the same object in different threads is not
>> >safe.  But it would be impossible to write thread safe code if some
>> >objects share some resources and the implementation does not document
>> >it.  Therefore, what are the classes that use or provide access to
>> >static members, global data, or singletons in a thread-unsafe manner?
>> >Are there any mechnisms to synchronize operations that might modify
>> >shared resources among objects?
>>
>> As mentioned, anything that throws is unsafe.  Currently, basic_string
>> is unsafe, and so is anything that allocates memory.
>
>egcs is shipped with the SGI version of STL, isn't it?  The following is
>quoted from SGI's STL page I just found: [...]

Note that Egcs-1.1 does not ship with the latest version of the SGI STL.
You need at least version 3.1 to get the thread-safety advertised on
SGI's page, if I am not mistaken, and I think Egcs-1.1 is still at
version 3.0.

>Looks a very reasonable design to me.  So I suppose I am on the safe side
>if I use egcs-1.1.

Do be sure to get the latest STL from SGI.  Note also that the STL
is only part of the standard library; the rest of libstdc++ is still
being worked on, and is not thread-safe by any definition.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 <6utvkv$7eg$1@shell7.ba.best.com>, Nathan Myers
<ncm@nospam.cantrip.org> writes
>Correct.  However, note also...
>Local static constructed variables, like
>
>  X& f() { X x; return x; }  // X::X() is a real function

I guess you meant X& f(){static X x; return x; }

>are also not currently thread-safe in Egcs either, nor indeed in
>most compilers that claim to be thread-safe.  You have to guard
>the initialization of these statics "manually".

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

Gilbert Chang <gchang@ccnet.com> wrote in article <3611A119.2E58D4C7@ccnet.com>...
> Oops, I meant to ask if the entire standard library implementation is thread-safe.
> Let me try again.  Anyone knows if the rest of std++ of egcs is thread-safe (an in
> what sense)?

I wrote:

>>> The current libstdc++ that comes with g++ is not thread-safe.
>>> Egcs-1.1, its successor, comes with essentially the same library,
>... note also:
>Local static constructed variables, like
>
>  X& f() { X x; return x; }

>are also not currently thread-safe in Egcs either, nor indeed in
>most compilers that claim to be thread-safe.  You have to guard
>the initialization of these statics "manually".

Of course I meant

  X& f() { static X x; return x; }  // X::X() does something

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

> Note that Egcs-1.1 does not ship with the latest version of the SGI STL.
> You need at least version 3.1 to get the thread-safety advertised on
> SGI's page, if I am not mistaken, and I think Egcs-1.1 is still at
> version 3.0.

> >Looks a very reasonable design to me.  So I suppose I am on the safe side
> >if I use egcs-1.1.

> Do be sure to get the latest STL from SGI.  Note also that the STL
> is only part of the standard library; the rest of libstdc++ is still
> being worked on, and is not thread-safe by any definition.
>

Hmm, I am a little disappointed.  Do you know when the rest of libstdc++ would
be at same thread-safety level as SGI's STL (3.1)?

Gilbert Chang



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

> The current libstdc++ that comes with g++ is not thread-safe.
> In fact, the exception handling in g++-2.8.x is not, either,
> so a conforming thread-safe library cannot be written for
> g++-2.8.x.
>
> Egcs-1.1, its successor, comes with essentially the same library,
> so it it not thread-safe yet.  However, the core language
> implementation *is* thread-safe, and the library is being
> rewritten, and will be thread-safe.

I thought the exception handlings in both g++2.8.x and egcs1.1 were
thread-safe.  Guess I have to use egcs1.1 if I want to be strict about thread
safety.

> >If not, how unsafe are they?  It's quite easy to cope with the situation
> >where invoking methods on the same object in different threads is not
> >safe.  But it would be impossible to write thread safe code if some
> >objects share some resources and the implementation does not document
> >it.  Therefore, what are the classes that use or provide access to
> >static members, global data, or singletons in a thread-unsafe manner?
> >Are there any mechnisms to synchronize operations that might modify
> >shared resources among objects?
>
> As mentioned, anything that throws is unsafe.  Currently, basic_string
> is unsafe, and so is anything that allocates memory.

egcs is shipped with the SGI version of STL, isn't it?  The following is
quoted from SGI's STL page I just found:

<quote start>
The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and simultaneous read
accesses to to
shared containers are safe. If multiple threads access a single container,
and at least one thread may potentially write, then the user is responsible
for ensuring mutual
exclusion between the threads during the container accesses.

This is the only way to ensure full performance for containers that do not
need concurrent access. Locking or other forms of synchronization are
typically expensive
and should be avoided when not necessary.
<quote end>

Looks a very reasonable design to me.  So I suppose I am on the safe side if
I use egcs1.1.

I think VC++5.0's STL has the same level of thread-safety if I apply the
fixes sugguested by Mr. Plauger.  Correct me if I am wrong.  Anybody knows
about VC++6.0?

Thanks

Gilbert Chang



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

Gilbert Chang <gchang@ccnet.com> wrote in article <36107DCA.C44DAF05@ccnet.com>...
> egcs is shipped with the SGI version of STL, isn't it?  The following is
> quoted from SGI's STL page I just found:
> .....
> Looks a very reasonable design to me.  So I suppose I am on the safe side if
> I use egcs1.1.

For the STL part, perhaps, but not the entire library. There's far more to the
Standard C++ library than STL.

> I think VC++5.0's STL has the same level of thread-safety if I apply the
> fixes sugguested by Mr. Plauger.  Correct me if I am wrong.  Anybody knows
> about VC++6.0?

Apply the same fixes and it too is thread safe, in the same sense as SGI.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html
---
[ 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              ]

Hi, folks:

I presume a compliant standard C++ library implementation does not need to be
thread safe.  If my presumption is correct, I would like to ask questions about
specific implementations: g++ 2.8.x and VC++ 5.0.

Are the formentioned standard C++ library implementations thread safe?  If not,
how unsafe are they?  It's quite easy to cope with the situation where invoking
methods on the same object in different threads is not safe.  But it would be
impossible to write thread safe code if some objects share some resources and
the implementation does not document it.  Therefore, what are the classes that
use or provide access to static members, global data, or singletons in a
thread-unsafe manner?  Are there any mechnisms to synchronize operations that
might modify shared resources among objects?

Thanks

Gilbert Chang





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

Gilbert Chang <gilbert@ia-us.com> wrote in article <360C393C.A24129E@ia-us.com>...
> I presume a compliant standard C++ library implementation does not need to be
> thread safe.  If my presumption is correct, I would like to ask questions about
> specific implementations: g++ 2.8.x and VC++ 5.0.
>
> Are the formentioned standard C++ library implementations thread safe?

VC++ V5.0 is thread safe (in the sense you seem to suggest) if you apply the
fixes at:

http://www.dinkumware.com/vc_fixes.html

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



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

 Gilbert Chang <gilbert@ia-us.com> wrote:
>I presume a compliant standard C++ library implementation does not need
>to be thread safe.  If my presumption is correct, I would like to ask
>questions about specific implementations: g++ 2.8.x and VC++ 5.0.
>
>Are the formentioned standard C++ library implementations thread safe?

The current libstdc++ that comes with g++ is not thread-safe.
In fact, the exception handling in g++-2.8.x is not, either,
so a conforming thread-safe library cannot be written for
g++-2.8.x.

Egcs-1.1, its successor, comes with essentially the same library,
so it it not thread-safe yet.  However, the core language
implementation *is* thread-safe, and the library is being
rewritten, and will be thread-safe.

>If not, how unsafe are they?  It's quite easy to cope with the situation
>where invoking methods on the same object in different threads is not
>safe.  But it would be impossible to write thread safe code if some
>objects share some resources and the implementation does not document
>it.  Therefore, what are the classes that use or provide access to
>static members, global data, or singletons in a thread-unsafe manner?
>Are there any mechnisms to synchronize operations that might modify
>shared resources among objects?

As mentioned, anything that throws is unsafe.  Currently, basic_string
is unsafe, and so is anything that allocates memory.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]