C++ and threads

8 views
Skip to first unread message

Alexander Terekhov

unread,
Feb 26, 2002, 1:42:53 PM2/26/02
to
It did not appear on c.l.c++mod (and I did not
receive moderation queue notification), so I'll
try c.std.c++.

-------- Original Message --------
Message-ID: <3C7A1401...@web.de>
Date: Mon, 25 Feb 2002 11:37:53 +0100
From: Alexander Terekhov <tere...@web.de>
Newsgroups: comp.lang.c++.moderated
Subject: C++ and threads (was: Re: throw() can be good for optimization)
References:
<6db3f637.02021...@posting.google.com><yRK5DeEWnjc8Ew$1...@robinton.ntlworld.com><OOKc8.69369$YA2.8...@news11-gui.server.ntli.net><g7gdpUE9...@robinton.ntlworld.com><9ZQc8.71299$YA2.9...@news11-gui.server.ntli.net><3C7420A7...@web.de><vV3d8.1239$H43.1...@news11-gui.server.ntli.net><3C75280D...@web.de><T1qd8.8301$H43.9...@news11-gui.server.ntli.net><3C765D08...@web.de>
<F6Pd8.22659$hM6.2...@news6-win.server.ntlworld.com>


Garry Lancaster wrote:
[...]
> > Not going into details of "useful" ES, as I see
> > it, I just want to make the following appeal:
> >
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > ! C++ Gurus, PLEASE start with SERIOUS considerations !
> > ! and design discussions with respect to *THREADS* !
> > ! integration into C++ language. !
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> That's a separate issue from the one
> we were discussing, although I am not blind to
> the fact that multi-threading affects just about
> everything.

Well, I guess that's not all that complicated/large-scale.
Other than thread(and async-cancel!)-safety throughout
the whole standard library, there are just a few areas
that need to be addressed, I think:

- integrate thread-cancel/exit with C++ exception model;
- static locals (lazy init);
- "static" thread locals (something along the lines of
__declspec(thread));
- word-tearing/false-sharing.

> I would be very surprised if multi-threading wasn't
> addressed in C++0x, but maybe not in the way,
> or to the extent, that you desire.

Why not? What's the problem with adopting the
MOST portable/reasonable/easy low level threading
model that exists out there -- *Pthreads*!? Also,
consider:

- MS have made their threading "standard" already:

Directory of G:\C#\tr-084\2001tc39-020b\System\Threading

10/02/2001 12:44p 546,816 Interlocked.doc
11/14/2001 05:38p 40,519 Interlocked.pdf
10/02/2001 12:44p 568,832 Monitor.doc
11/14/2001 05:36p 56,873 Monitor.pdf
10/02/2001 12:44p 30,208 SynchronizationLockException.doc
11/14/2001 05:36p 20,093 SynchronizationLockException.pdf
10/02/2001 12:44p 686,080 Thread.doc
11/14/2001 05:36p 138,010 Thread.pdf
10/02/2001 12:45p 26,624 ThreadAbortException.doc
11/14/2001 05:36p 17,664 ThreadAbortException.pdf
10/02/2001 12:44p 26,624 ThreadPriority.doc
11/14/2001 05:36p 18,577 ThreadPriority.pdf
10/02/2001 12:45p 21,504 ThreadStart.doc
11/14/2001 05:37p 13,391 ThreadStart.pdf
10/02/2001 12:44p 34,816 ThreadState.doc
11/14/2001 05:37p 23,926 ThreadState.pdf
10/02/2001 12:45p 32,256 ThreadStateException.doc
11/14/2001 05:37p 21,215 ThreadStateException.pdf
10/02/2001 12:45p 22,016 Timeout.doc
11/14/2001 05:37p 14,015 Timeout.pdf
10/02/2001 12:45p 546,816 Timer.doc
11/14/2001 05:37p 41,480 Timer.pdf
10/02/2001 12:45p 23,552 TimerCallback.doc
11/14/2001 05:37p 14,747 TimerCallback.pdf
10/02/2001 12:43p 530,944 WaitHandle.doc
11/14/2001 05:35p 30,514 WaitHandle.pdf
26 File(s) 3,548,112 bytes

more info:

http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0938.html

Just think of their "Managed Extensions for C++ Specification":


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/html/vcManagedExtensionsSpec_Start.asp
("This document describes the Managed Extensions for the
Visual C++ programming language. These extensions encompass
a set of features that will support the common type system
and the common language runtime. The Managed Extensions are
compatible with the C++ ISO Standard."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Gee! Gee! Gee! Gee! Gee! Gee! Gee!)

- Java is slowly gravitating "back" towards Pthreads:
(well, with less "undefined" behaviors, though ;-))

http://gee.cs.oswego.edu/dl/concurrency-interest/aims.html

> So, don't just sit there; you obviously feel strongly
> about the issue and have relevant
> expertise

Thanks for the compliment. I must confess, however,
that all of my knowledge/expertise is rather limited
by a couple of years of horror nightmares at sleep when
I was programming win32/Java threads only and a nice
relaxation since a year or so ago when I've learned
PTHREADS from the standard documents and Butenhof's PWPT
(*TWO* volumes ;-)) - the second volume is free and is
available on Compaq web site. It is called "Tru64 UNIX/
Guide to the POSIX Threads Library" ;-)

> so why not contribute to the standardization
> process yourself?

Do you mean that I should write a complete proposal
and post it to comp.std.c++? Sorry, I can't do it.

> The idea that only "C++ Gurus"
> (whatever that means) have anything to offer sets
> the bar a little too high in my opinion.

My friend dictionary says ("Guru"):

"A revered teacher or mentor. A recognized
leader: The guru of high finance. [ From
Sanskrit guru-, venerable]"

As for my part, I am always ready to
provide some feedback...quibbles! ;-)

Also, there is some sketchy stuff from
me available here:

http://groups.google.com/groups?as_umsgid=c29b5e33.0202121053.273318c0%40posting.google.com
http://groups.google.com/groups?as_umsgid=c29b5e33.0202140422.203f1141%40posting.google.com

regards,
alexander.

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

Ian Collins

unread,
Feb 28, 2002, 8:00:55 PM2/28/02
to
Alexander Terekhov wrote:
<snip>

>
> Garry Lancaster wrote:
> [...]
> > > Not going into details of "useful" ES, as I see
> > > it, I just want to make the following appeal:
> > >
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > ! C++ Gurus, PLEASE start with SERIOUS considerations !
> > > ! and design discussions with respect to *THREADS* !
> > > ! integration into C++ language. !
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> > That's a separate issue from the one
> > we were discussing, although I am not blind to
> > the fact that multi-threading affects just about
> > everything.
>
> Well, I guess that's not all that complicated/large-scale.
> Other than thread(and async-cancel!)-safety throughout
> the whole standard library, there are just a few areas
> that need to be addressed, I think:
>
> - integrate thread-cancel/exit with C++ exception model;

How? Who would catch the exception? If a cancellation request resulted
in an exception, the thread could just ignore it.

Maybe some input form the Java or ADA community would help to identify
the pros and cons of built in threads.

Ian

<snip>

Ian Collins
Masuma Ltd,
Christchurch
New Zealand.

Garry Lancaster

unread,
Mar 1, 2002, 10:46:43 AM3/1/02
to
Alexander Terekhov:

> > > Not going into details of "useful" ES, as I see
> > > it, I just want to make the following appeal:
> > >
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > ! C++ Gurus, PLEASE start with SERIOUS considerations !
> > > ! and design discussions with respect to *THREADS* !
> > > ! integration into C++ language. !
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Garry Lancaster:


> > That's a separate issue from the one
> > we were discussing, although I am not blind to
> > the fact that multi-threading affects just about
> > everything.

Alexander Terekhov:


> Well, I guess that's not all that complicated/large-scale.
> Other than thread(and async-cancel!)-safety throughout
> the whole standard library,

I reckon that's a big job.

> there are just a few areas
> that need to be addressed, I think:
>
> - integrate thread-cancel/exit with C++ exception model;

If I understand you correctly, you are proposing
that a thread could inject an exception into
another thread.

I don't like this. At the moment in C++ we can
tell where exceptions are thrown. Async exceptions
have a particularly unpleasant effect on no-throw
code i.e. it isn't no-throw anymore

I believe some C++ implementations already
use asynchrounous exceptions as an extension.
How do they deal with the problems? I guess
they have some kind of mechanism for
switching async exceptions off and on, in which
case I hope it's off by default.

My impression, from a great book on Java
threading I was reading recently, is that Java
initially supported thread termination using
async exceptions, but is moving away from
that as it was just too weird.

> - static locals (lazy init);
> - "static" thread locals (something along the lines of
> __declspec(thread));
> - word-tearing/false-sharing.

All good points.

What about synchronisation primitives? boost::thread
is a good start but it's my impression that integrating
mutexes into the core language a la Java could provide
some benefits. I'm thinking particularly that the code
re-ordering rules could be made sync block aware.

> > I would be very surprised if multi-threading wasn't
> > addressed in C++0x, but maybe not in the way,
> > or to the extent, that you desire.
>
> Why not?

For a start because people rarely agree 100% on the
subject.

> What's the problem with adopting the
> MOST portable/reasonable/easy low level threading
> model that exists out there -- *Pthreads*!?

I believe boost::thread is more portable. It uses
pthreads underneath for some platforms and
Win32 threading underneath on, ahem, Win32.

I don't think the non-OO nature of the raw pthreads
interface sits comfortably with the rest of the
standard lib. It needs wrapping at the very least.

> Also, consider:
>
> - MS have made their threading "standard" already:

[snip stuff on .net threading types]

As you know, they have a number of threading "standards",
and that one requires the .net runtime. It's not a reason
to exclude MS implementations from a C++ threading
standard. A C++ threading standard needs to be general
enough that it can wrap each of the most common
threading APIs/object models. Did I mention
boost::thread? ;-)

> > So, don't just sit there; you obviously feel strongly
> > about the issue and have relevant
> > expertise
>
> Thanks for the compliment. I must confess, however,
> that all of my knowledge/expertise is rather limited
> by a couple of years of horror nightmares at sleep when
> I was programming win32/Java threads only and a nice
> relaxation since a year or so ago when I've learned
> PTHREADS from the standard documents and Butenhof's PWPT
> (*TWO* volumes ;-)) - the second volume is free and is
> available on Compaq web site. It is called "Tru64 UNIX/
> Guide to the POSIX Threads Library" ;-)

That sounds like a pretty good grounding in
threads to me, but it's difficult to tell purely
on the basis of how long someone has been
doing something and how much they have
read. Some people are naturals, some just
never get it. The rest of us sit in the middle.
There is always more to learn for anyone.

> > so why not contribute to the standardization
> > process yourself?
>
> Do you mean that I should write a complete proposal
> and post it to comp.std.c++? Sorry, I can't do it.

There are many other ways to contribute. For
example, the ISO mailing lists. Yes, there are
mailing lists separate to comp.std.c++ where
standaridization issues are discussed! The
culture is a little different to the NGs - usually
the standard of debate is higher and the
approach less adversarial (and I'd like it to stay
that way). Sometimes real work is done.

> > The idea that only "C++ Gurus"
> > (whatever that means) have anything to offer sets
> > the bar a little too high in my opinion.
>
> My friend dictionary says ("Guru"):
>
> "A revered teacher or mentor. A recognized
> leader: The guru of high finance. [ From
> Sanskrit guru-, venerable]"

The problem with the idea that everyone
on the standards committee is a guru is
that it encourages an "us and them" view
of things. In the worse case, this leads to
trenchant criticism of aspects of the language
standard emerging *after* standardization,
in forums such as this, rather than *before*
standardization in the ISO forums.

Anyone who spots a problem with the next
C++ standard after it is released will in a
sense be partly to blame for that situation.
They had the chance to spot it beforehand
but they didn't take it. (Not that assigning
blame is the aim - the aim is to make C++0x
as good as possible. First time.)

> As for my part, I am always ready to
> provide some feedback...quibbles! ;-)

And that would be helpful, provided they
are accurate quibbles. But you won't
have access to all the relevant discussions
unless you join in the standardization effort.

If anyone is interested, they should find out
who their ISO contact is for their country of
residence and ask them what it's all about.

Interesting stuff although I find your writing
style very condensed at times, so I don't
always follow. On this group you can assume
a certain fairly high level of C++ knowledge as
a minimum. But the level of multi-threaded
expertise is much wider. If you give more
explanations of your points, more people will
be able to follow you.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

Alexander Terekhov

unread,
Mar 1, 2002, 1:34:09 PM3/1/02
to

Ian Collins wrote:
[...]

> > Well, I guess that's not all that complicated/large-scale.
> > Other than thread(and async-cancel!)-safety throughout
> > the whole standard library, there are just a few areas
> > that need to be addressed, I think:
> >
> > - integrate thread-cancel/exit with C++ exception model;
>
> How? Who would catch the exception?

Implementation; just like pthread_cancel_e exception; see:

http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_PDF/ARH9RBTE.PDF

and/or the second link below (I mean *source code*
and source code comments).

> If a cancellation request resulted
> in an exception, the thread could just ignore it.

Right, finalization of cancel-exceptions in the user
code IS in the uncharted territory, AFAIK/AFAICT.
(Java's "interrupt"-model aside, see below)

One "problem"/question is the interactions w.r.t
cancel state and type (thread cancelability) and
"eating"/finalization handler. It is my understanding
that thread's cancelability is DISABLED once the
cancel/unwind process gets under way - cancel-exception
gets thrown/raised (and since it could be initiated
from some async-cancel-region, the type could just
remain ASYNCHRONOUS, suppressed by DISABLE type...
AND/OR even something else; see:

http://sources.redhat.com/pthreads-win32

for example).

On the other hand, you are really (most likely)
want/need to get things back as usual, in-order:

state: ENABLED
type: DEFERRED
============== ================
cancelability: ENABLED/DEFERRED

ON THE EXIT from that finalize/catch-and-just-eat'em
cancel-exception handler, IMHO.

I've asked Butenhof on c.p.t -- no answer yet:

http://groups.google.com/groups?as_umsgid=c29b5e33.0202150920.4c9f991a%40posting.google.com

Also, Butenhof "once" mentioned "exception-aware"
"UNIX 98 ABI for IA-64" draft document:

http://groups.google.com/groups?as_umsgid=kZ7h7.623%24bB1.30401%40news.cpqcorp.net
http://groups.google.com/groups?as_umsgid=3AF00403.C9498C92%40compaq.com

I am now trying to get access/find that "dead"
document... perhaps someone could help.

I guess that it will point to the similar
ideas/concepts that are explained in:

http://groups.google.com/groups?as_umsgid=c29b5e33.0202271136.23b99325%40posting.google.com
(see "nonlocal GOTO in a multilanguage environment" item)

> Maybe some input form the Java or ADA community would help to identify
> the pros and cons of built in threads.

Don't know about ADA, but the URL above does point
to some Java stuff (sort of pros and cons). ;-)

regards,
alexander.

Alexander Terekhov

unread,
Mar 1, 2002, 3:40:34 PM3/1/02
to

Garry Lancaster wrote:
[...]

> I believe some C++ implementations already
> use asynchrounous exceptions as an extension.
> How do they deal with the problems? I guess
> they have some kind of mechanism for
> switching async exceptions off and on, in which
> case I hope it's off by default.

Yep.

> My impression, from a great book on Java
> threading I was reading recently, is that Java
> initially supported thread termination using
> async exceptions, but is moving away from
> that as it was just too weird.

Well, I assume you mean the deprecated
stop/ThreadDeath exception. The whole
concept was indeed broken due to the lack
of *async-cancel-safety*-Pthreads like
thing. However, RTJ spec/extension attempts
to fix/revive it... see the link in my other
post here.

> > - static locals (lazy init);
> > - "static" thread locals (something along the lines of
> > __declspec(thread));
> > - word-tearing/false-sharing.
>
> All good points.
>
> What about synchronisation primitives?

You don't really need anything other than
<cthread>/<pthread.h> locks, barriers and
condvars! ;-)

> boost::thread is a good start

boost::thread is just a thin object layer
on top of Pthreads, nothing else! And
it lacks (currently) A LOT; the whole
concept of thread-/mutex-/condvars-
attributes (runtime polymorphism) have
yet to be integrated into boost.threads,
for example.

boost.threads efforts should transform
into <thread> header... but that does NOT
mean that <cthread> header should not become
a part of future thread-aware C++ too, I think!

> but it's my impression that integrating
> mutexes into the core language a la Java could provide
> some benefits.

AFAICT that's just syntactical sugar...
also consider that JSR-166 intends to provide
Pthread-like locks with explicit methods
(and Pthread-like attributes too)!

> I'm thinking particularly that the code
> re-ordering rules could be made sync block aware.

I never understood that magic. Java's memory model
just mimics Pthreads with some "extensions" (volatiles,
etc) which makes it EXTREMELY complicated, well
to me, at least. And, BTW, both need post-/pre-
c-/d-tors! ;-) ;-) (well, post-ctors only for
poor Java which lacks d-tors/RAI ;-)).

> > > I would be very surprised if multi-threading wasn't
> > > addressed in C++0x, but maybe not in the way,
> > > or to the extent, that you desire.
> >
> > Why not?
>
> For a start because people rarely agree 100% on the
> subject.

The subject (Pthreads) is for the long time around us,
and working just fine for many years already... simply
"emulating" C++ exceptions/cleanup in C using thread_cleanup
handlers! ;-)

> > What's the problem with adopting the
> > MOST portable/reasonable/easy low level threading
> > model that exists out there -- *Pthreads*!?
>
> I believe boost::thread is more portable.

I don't think so. It is just a POOR re-invention
(I would even call/label it as "FORK") of things/
projects like pthread-win32 with a thin object layer
added on top of it. I do not want to go into details,
but for example, think of Apple/MAC and their
"commercial"/official Pthreads impl once it become
fully ready.

> It uses
> pthreads underneath for some platforms and
> Win32 threading underneath on, ahem, Win32.

Win32 has Pthreads too (with more than just
one maintainer/main-contributor, BTW).

> I don't think the non-OO nature of the raw pthreads
> interface sits comfortably with the rest of the
> standard lib. It needs wrapping at the very least.

<cthread> is non-OO (fully compatible with <pthread.h>);

<thread> is OO, less error prone (gets rid of detach,
provides scoped locking, etc) implemented in terms of
<cthread> -- providing the same effects.

What's the problem?

regards,
alexander.

Garry Lancaster

unread,
Mar 2, 2002, 12:08:47 PM3/2/02
to
> Garry Lancaster wrote:
> > My impression, from a great book on Java
> > threading I was reading recently, is that Java
> > initially supported thread termination using
> > async exceptions, but is moving away from
> > that as it was just too weird.

Alexander Terekhov:


> Well, I assume you mean the deprecated
> stop/ThreadDeath exception. The whole
> concept was indeed broken due to the lack
> of *async-cancel-safety*-Pthreads like
> thing. However, RTJ spec/extension attempts
> to fix/revive it... see the link in my other
> post here.

Yeah, I think that's what I meant. (Have mislaid
book though so can't be sure ;-)

Are asynchronous exceptions useful enough
to counteract the problems they pose for
the standardization team (having to retrofit the
concept of async-cancel-safety everywhere - in
fact all library vendors would be under pressure
to do this) and novices? (Yes, I know that people
shouldn't use things they don't understand, but
in reality they do, they do...)

In one of your links (I'm sorry I forget which one)
someone wrote something like "they aren't
useful 99% of the time". If that's a fair assessment
I would say they weren't worth adding to C++.

[snip]

> > boost::thread is a good start
>
> boost::thread is just a thin object layer
> on top of Pthreads, nothing else!

Well, that's not quite true, as you admit yourself
later on, as it wraps Win32 primitives as well.

[snip]

> > but it's my impression that integrating
> > mutexes into the core language a la Java could provide
> > some benefits.
>
> AFAICT that's just syntactical sugar...
> also consider that JSR-166 intends to provide
> Pthread-like locks with explicit methods
> (and Pthread-like attributes too)!

OK. If we are going to take pthreads as the basis
for a C++ threading standard, I guess we
should fiddle with it as little as possible lest
we break it.

> > I'm thinking particularly that the code
> > re-ordering rules could be made sync block aware.
>
> I never understood that magic. Java's memory model
> just mimics Pthreads with some "extensions" (volatiles,
> etc) which makes it EXTREMELY complicated, well
> to me, at least. And, BTW, both need post-/pre-
> c-/d-tors! ;-) ;-) (well, post-ctors only for
> poor Java which lacks d-tors/RAI ;-)).

Why? And once you do that why stop there? People
will start asking for pre-pre-ctors and post-post-dtors.

> > > > I would be very surprised if multi-threading wasn't
> > > > addressed in C++0x, but maybe not in the way,
> > > > or to the extent, that you desire.
> > >
> > > Why not?
> >
> > For a start because people rarely agree 100% on the
> > subject.
>
> The subject (Pthreads) is for the long time around us,
> and working just fine for many years already... simply
> "emulating" C++ exceptions/cleanup in C using thread_cleanup
> handlers! ;-)

The subject isn't Pthreads, the subject is C++
threading. You may wish them to be one and
the same, but they're not. At least not yet.

> > > What's the problem with adopting the
> > > MOST portable/reasonable/easy low level threading
> > > model that exists out there -- *Pthreads*!?
> >
> > I believe boost::thread is more portable.
>
> I don't think so. It is just a POOR re-invention
> (I would even call/label it as "FORK") of things/
> projects like pthread-win32 with a thin object layer
> added on top of it.

I don't think shouting that it is poor is constructive.
For a start you will gratuitously offend the people
who spent their own time writing it (for no monetary
gain) if they happen to read your post. It is OK to
prefer pthreads though and it is OK to say why.

> I do not want to go into details,
> but for example, think of Apple/MAC and their
> "commercial"/official Pthreads impl once it become
> fully ready.

I'm afraid I'm not familiar with this. Could you
explain what you mean?

> > It uses
> > pthreads underneath for some platforms and
> > Win32 threading underneath on, ahem, Win32.
>
> Win32 has Pthreads too (with more than just
> one maintainer/main-contributor, BTW).

This is a project governed by the LGPL which means
it would be freely available to compiler and std lib
vendors to add to their products. It could fly, although
I notice it is currently not a complete implementation
of pthreads.

[snip]

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

John Nagle

unread,
Mar 2, 2002, 2:28:42 PM3/2/02
to
Alexander Terekhov wrote:

> You don't really need anything other than <cthread>/<pthread.h>
> locks, barriers and condvars! ;-)

As a code generation issue, there's a sizable performance gain to
implementing locking as an inline primitive. On many hardware
platforms, locking can be implemented without a system call, yet many
libraries use a system call on every lock/unlock action. This is often
because specific machine instructions are required; you can't write "do
this as an atomic operation" in C or C++.

The view of locking in C++ as expensive has distorted system
architectures.

John Nagle
Animats

Alexander Terekhov

unread,
Mar 3, 2002, 4:09:40 AM3/3/02
to

Garry Lancaster wrote:
[...]

> I don't like this. At the moment in C++ we can
> tell where exceptions are thrown. Async exceptions
> have a particularly unpleasant effect on no-throw
> code i.e. it isn't no-throw anymore
>
> I believe some C++ implementations already
> use asynchrounous exceptions as an extension.
> How do they deal with the problems? I guess
> they have some kind of mechanism for
> switching async exceptions off and on, in which
> case I hope it's off by default.

Apropos async-exceptions/cancel, perhaps the
following "reject: [off-topic]"/"fail to the
the relevance to C++ anymore" post from
c.l.c++.mods IS *on-topic* here, in THIS
"C++ and threads" discussion... Gee!

---
Message-Id: <2002030122...@netlab.cs.rpi.edu>
From: c++-r...@netlab.cs.rpi.edu
To: tere...@web.de
Cc: c++-r...@netlab.cs.rpi.edu
Subject: reject: [off-topic]


Message-ID: <3C7FE9D6...@web.de>
Newsgroups: comp.lang.c++.moderated
From: Alexander Terekhov <tere...@web.de>
Subject: Re: throw() can be good for optimization

{I fail to the the relevance to C++ anymore. At the same time, the
article does not have a "Followup-To:" header set which would redirect
it to some more appropriate forum. Thus, this article is rejected from
comp.lang.c++.moderated. -mod}

"Hillel Y. Sims" wrote:
[...]
> The default mode is enabled & synchronous. Synchronous meaning cancellation
> is only a request made by the calling thread that can remain pending
> possibly indefinitely, and actual exception or signal can only be raised in
> the target thread at certain specified function call points. Asynchronous
> mode is used very infrequently, because it really is unsafe in 99% of
> circumstances.

Yup, however:

http://groups.google.com/groups?as_umsgid=3C2CC94A.503FB8E2%40web.de

"...To me, why bother with
pthread_testcancel() injecting it at some
point(s) inside some long computation loop
that does not invoke any async-cancel-unsafe
operations? Why not just have cancel type set
to PTHREAD_CANCEL_ASYNCHRONOUS inside such
async-cancel-safe region?!"

http://groups.google.com/groups?as_umsgid=3C3073B3.A34EC44D%40web.de

"...Well, why not just treat the whole async-cancel-region
as a single (but rather fatty ;) deferred cancellation
point? I do not see any additional situations here (except
an obvious need for async-cancel-safety to form a region).
If you need some cleanup to release something and/or
restore/fix shared objects invariants just do it; set up
your cleanup prior to setting PTHREAD_CANCEL_ASYNCHRONOUS
cancel type on async-cancel-region entry and dismiss
your cleanup (optionally invoking it) at some point after
you have set cancel type back to PTHREAD_CANCEL_DEFFERED
on async-cancel-region exit."

http://groups.google.com/groups?as_umsgid=3B72FCBE.5F7358FF%40web.de

"you should use asynch. cancellation only in the functions/code
fragments which do not need any cleanup and do not call any
asynch.cancel-unsafe functions (such as _push/_pop) with
asynch.cancellation enabled. however, you could simply
disable asynch. cancellation, acquire resources, setup
cleanup handler(s) and enable asynch. cancellation again;
do some asynch. cancelable operations, disable asynch.
cancellation, release resources/pop handlers and
enable asynch. cancellation again,..."

regards,
alexander.

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


======================================= MODERATOR'S COMMENT:
This article is even less relavent to C++, since it does not mention standardization at all... watch followups!

John Nagle

unread,
Mar 3, 2002, 6:29:15 PM3/3/02
to
It's quite possible to make asynchronous
exceptions work, at least on most current processors.
Any CPU that can back out a page fault can do clean
exception handling. This was done in Ada years ago.

The key idea is that for each address in the
executable program, there must be a unique recovery
action. Given that, all that's needed is a table
of address ranges vs. recovery points. On an
interrupt, the recovery point table is searched for
the appropriate address, and control is then
transferred to the recovery handler for that point.

This is similar to the mechanism used now
to allow code with intermixed declaration and "throw"
statements. It's just more fine-grained.

There are other obvious implementations, involving
periodic checks in the code, but they're slower.

The ability to defer asynchronous exceptions
during critical sections is useful if this is
to work.

John Nagle
Animats

Alexander Terekhov wrote:

> Garry Lancaster wrote:
> [...]
>
>>I don't like this. At the moment in C++ we can
>>tell where exceptions are thrown. Async exceptions
>>have a particularly unpleasant effect on no-throw
>>code i.e. it isn't no-throw anymore
>>
>>I believe some C++ implementations already
>>use asynchrounous exceptions as an extension.
>>How do they deal with the problems?

---

Alexander Terekhov

unread,
Mar 4, 2002, 10:29:19 AM3/4/02
to

John Nagle wrote:
>
> Alexander Terekhov wrote:
>
> > You don't really need anything other than <cthread>/<pthread.h>
> > locks, barriers and condvars! ;-)
>
> As a code generation issue, there's a sizable performance gain to
> implementing locking as an inline primitive. On many hardware
> platforms, locking can be implemented without a system call,

Library call (pthread.h/whatever) != "system call" and could
easily be implemented as "inline primitive", with some "system
call" providing handling of CONTENTION case only, AFAIK.

regards,
alexander.

Garry Lancaster

unread,
Mar 4, 2002, 10:30:22 AM3/4/02
to
John Nagle:

> It's quite possible to make asynchronous
> exceptions work, at least on most current processors.
> Any CPU that can back out a page fault can do clean
> exception handling. This was done in Ada years ago.

I'm not doubting that it's possible, at least on some
processors. More whether it is worth the trouble.

The problems of async exceptions are that

1. To benefit, the programmer must write at least some
async-cancel-safe code. In other words code that
can be interrupted at any point and still be able
to maintain the exception safety guarantee it offers.
(This will be either the strong or basic exception
safety guarantee; no-throw doesn't make sense
here.) That's more work for the programmer,
including, but not limited to, standard library
writers.

2. It is very easy to get this wrong. (Of course the
same argument could be made, indeed has been
made, about synchronous exception safety. In
both cases it is a legitimate demerit of the
approach.) As Allen I. Holub memorably phrased
it, in a different context, you have "enough rope to
shoot yourself in the foot".

3. The language must be altered to support
async-exceptions. That's more work for compiler
writers and the standardisation team.

Even without async exceptions, it is still possible
to cancel a thread. The benefit of async exceptions
is supposed to be that the code dealing with thread
cancellation is cleaner and more responsive.
I'm dubious as to how often, and to what extent,
this benefit is realised. Let me explain...

I believe I'm correct in saying that there are some
code sequences that can never be made async
cancel safe. Even if I'm wrong here, you can bet
that there are some where the efficiency cost of
async cancel safety is so high that it will not be
implemented.

My supposition is that most code you want to
cancel asynchronously will contain a number of
these non-async-cancel-safe blocks, necessitating
a switch to deferred handling at the beginning
of the block and a switch back to true async
handling after the block. These blocks may
or may not be function calls.

The more of this switching you have going on,
the less benefit you are deriving from the
theoretical cleanness and responsiveness of
the async exception cancellation system.

My contention is that the residual benefit is
insufficient to cancel out the demerits I listed
and that, therefore, there is insufficient reason
to adopt async exceptions in C++.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Alexander Terekhov

unread,
Mar 4, 2002, 10:30:30 AM3/4/02
to

Garry Lancaster wrote:
[...]

> Are asynchronous exceptions useful enough
> to counteract the problems they pose for
> the standardization team (having to retrofit the
> concept of async-cancel-safety everywhere - in
> fact all library vendors would be under pressure
> to do this) and novices? (Yes, I know that people
> shouldn't use things they don't understand, but
> in reality they do, they do...)
>
> In one of your links (I'm sorry I forget which one)
> someone wrote something like "they aren't
> useful 99% of the time". If that's a fair assessment
> I would say they weren't worth adding to C++.

A few days ago I've posted here the rejected
c.l.c++.mod article which I think does address
this "they aren't useful 99% of the time"/"NOT
worth C++ standardization" point.

[...]


> > > boost::thread is a good start
> >
> > boost::thread is just a thin object layer
> > on top of Pthreads, nothing else!
>
> Well, that's not quite true, as you admit yourself
> later on, as it wraps Win32 primitives as well.

Well, what else should it "wrap"... on win32? ;-)

Technical aspects/functionality (current) of
"wrapping" aside, boost.thread just ignores
zillions lines of PORTABLE *C++* Pthread-ed
code (cancellation aside). <cthread> could
and SHOULD address this issue (including
{async}cancel/C++, this time!), I think.
<thread> should basically do the same to
<cthread> as <iostream>/<fstream> did to
<cstdio>:

"The header <iostream> declares objects that
associate objects with the standard C streams
provided for by the functions declared in
<cstdio> (27.8.2)."

"basic_filebuf<charT,traits>* open(
const char* s,ios_base::openmode mode );

2 Effects: If is_open() != false, returns a null pointer. Otherwise,
initializes the filebuf as required. It then opens a file,
if possible, whose name is the NTBS s
("as if" by calling std::fopen( s, modstr)).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"

"Table 92-File open modes
...
ios_base Flag combination stdio equivalent
^^^^^^^^^^^^^^^^"

etc... I hope you see the point, I just
do not want to repeat that "better way
of coding Pthreads" stuff again (also,
see "e-mail" item below).

[...]


> > And, BTW, both need post-/pre-
> > c-/d-tors! ;-) ;-) (well, post-ctors only for
> > poor Java which lacks d-tors/RAI ;-)).
>
> Why? And once you do that why stop there? People
> will start asking for pre-pre-ctors and post-post-dtors.

I have yet to see a C++ (or Java) class with sort
of init() AND init2(), init3()... methods. Perhaps
we just have a different understanding of what
post-/pre- c-/d-tors should do/what "problems"
should they address...

[...]


> > > I believe boost::thread is more portable.
> >
> > I don't think so. It is just a POOR re-invention
> > (I would even call/label it as "FORK") of things/
> > projects like pthread-win32 with a thin object layer
> > added on top of it.
>
> I don't think shouting that it is poor is constructive.

Boldface formatting "just" adds *emphasis". If you
consider it as "shouting" generally/altogether (or as
just silly annoyance preventing/disturbing "matured"
readers from reading by outline) that's your choice.
But your comment/reaction does indicate that you did
NOT miss the point... ;-) so I'm satisfied. ;-) ;-)

> For a start you will gratuitously offend the people
> who spent their own time writing it (for no monetary
> gain) if they happen to read your post.

a) I spent quite a lot of my own time on boost.org
and even contributed (for no monetary gain ;-))
some of the stuff used in the current boost.thread.

b) well, AFAIK, I am already on the "kill" list
of W.Kempf! ;-)

> It is OK to
> prefer pthreads though and it is OK to say why.

[...]


> > I do not want to go into details,
> > but for example, think of Apple/MAC and their
> > "commercial"/official Pthreads impl once it become
> > fully ready.
>
> I'm afraid I'm not familiar with this. Could you
> explain what you mean?

I mean roughly this:

< from an e-mail I've sent to W.Kempf some time ago >

"> > > Are you saying that pthread_* calls implemented
> > > on top of some other proprietary platform specific
> > > primitives/interfaces are NOT "native"? For example,
> > > is SUN's *Solaris proprietary LWP interfaces* more
> > > native than SUN's Solaris pthread implementation?
> > > What is the principle difference with respect to
> > > MS-WIN proprietary API and some win32 pthread
> > > implemenation?
> >
> > "Native" simply means the API used by the Boost.Threads
> > implementation.
>
> Personally, I strongly believe that you are going
> to make a HUGE mistake here. It is just absolutely
> pointless to even consider zillions of proprietary
> threading API's available out there. Instead,
> you should just concentrate on THE STANDARD
> called PTHREADS making Boost.Threads just a
> better way to code PTHREADS - just like C++ file
> streams is a better way to code standard C file I/O.
> One simple reason is that you could NEVER beat
> professional/supported PTHREAD impls - boost::condition,
> for example, has a chance close to NULL of beating
> pthreads-win32/pthreads-mac(from Apple)/etc PTHREAD
> condition vars! Consider that pthreads-win32 is likely
> to provide a real pthread_mutex_timedlock() function
> (in its next "snapshot"), which will work with all
> PTHREAD mutex types with a speed of MS critical section.
> Can you do this? Even if yes, what is the purpose of
> reinventing the bicycle?!"

And, BTW, the freshly new pthreads-win32 snapshot IS
out now. See http://sources.redhat.com/pthreads-win32
for details...

> > > It uses
> > > pthreads underneath for some platforms and
> > > Win32 threading underneath on, ahem, Win32.
> >
> > Win32 has Pthreads too (with more than just
> > one maintainer/main-contributor, BTW).
>
> This is a project governed by the LGPL which means
> it would be freely available to compiler and std lib
> vendors to add to their products. It could fly, although
> I notice it is currently not a complete implementation
> of pthreads.

Only Microsoft could make it "complete", I mean
FULL implementation of IEEE Std 1003.1-2001.
Also, consider (see "COPYING" in CVS):

"Although pthreads-win32 makes it possible for applications
that use POSIX threads to be ported to Win32 platforms, the
broader goal of the project is to encourage the use of open
standards, and in particular, to make it just a little easier
for developers writing Win32 applications to consider
widening the potential market for their products"

regards,
alexander.

Hyman Rosen

unread,
Mar 4, 2002, 12:16:44 PM3/4/02
to
John Nagle wrote:
> It's quite possible to make asynchronous
> exceptions work, at least on most current processors.
> Any CPU that can back out a page fault can do clean
> exception handling. This was done in Ada years ago.

<http://groups.google.com/groups?hl=en&selm=dewar.899945858%40merv>
from Robert Dewar, an Ada luminary and one of the main GNAT creators
refers to ATC (asynchronous transfer of control) as an abomination.

Garry Lancaster

unread,
Mar 4, 2002, 12:28:39 PM3/4/02
to
Alexander Terekhov:

> > > And, BTW, both need post-/pre-
> > > c-/d-tors! ;-) ;-) (well, post-ctors only for
> > > poor Java which lacks d-tors/RAI ;-)).

Garry Lancaster:


> > Why? And once you do that why stop there? People
> > will start asking for pre-pre-ctors and post-post-dtors.

Alexander Terekhov:


> I have yet to see a C++ (or Java) class with sort
> of init() AND init2(), init3()... methods.

And that, I suggest, is a good thing.

When I see init(), and it is intended for the client
to call (rather than a private function that multiple
ctors forward to) I start to think the class is
designed badly; that the person who designed it
didn't really understand how constructors worked
and/or had never come across the number of
design patterns that support more complex object
creation scenarios (Factory Method, Builder,
Prototype etc.) The presence of init2() and init3()
would tend to confirm that impression.

> Perhaps
> we just have a different understanding of what
> post-/pre- c-/d-tors should do/what "problems"
> should they address...

Quite possibly, as I don't see a need for any of
them. Let me expand on my first "Why?": why do
you want post-ctors, pre-ctors, post-dtors and
pre-dtors and how do you want them to work?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Matthew Austern

unread,
Mar 4, 2002, 12:46:03 PM3/4/02
to
John Nagle <na...@animats.com> writes:

> It's quite possible to make asynchronous
> exceptions work, at least on most current processors.
> Any CPU that can back out a page fault can do clean
> exception handling. This was done in Ada years ago.

The question isn't whether it's possible to implement asynchronous
exceptions; it's whether such an implementation would be usable.

Writing exception-safe code in C++ requires that you reason about
which exceptions can occur at which points. With asynchronous
exception handling, that's no longer possible; you can no longer
write functions with the nothrow guarantee, or rely on the nothrow
guarantee from functions that someone else wrote. I don't know
how I could write reliable code without having that guarantee.

Garry Lancaster

unread,
Mar 4, 2002, 1:32:56 PM3/4/02
to
Alexander Terekhov:

> Technical aspects/functionality (current) of
> "wrapping" aside, boost.thread just ignores
> zillions lines of PORTABLE *C++* Pthread-ed
> code (cancellation aside).

It's portable between any two pthreads
implementations that share the same de-facto
pthreads-C++ binding, since there is no standard
pthreads-C++ binding.

The whole point of standardization is to achieve
a greater degree of portability than that. OK,
pthreads could be a good starting point, but
let's look at all the options.

Garry Lancaster:


> > > > I believe boost::thread is more portable.

Alexander Terekhov:


> > > I don't think so. It is just a POOR re-invention
> > > (I would even call/label it as "FORK") of things/
> > > projects like pthread-win32 with a thin object layer
> > > added on top of it.
> >
> > I don't think shouting that it is poor is constructive.
>
> Boldface formatting "just" adds *emphasis". If you
> consider it as "shouting" generally/altogether (or as
> just silly annoyance preventing/disturbing "matured"
> readers from reading by outline) that's your choice.

I believe it's commonly known as shouting. If I'm
wrong I apologise.

> But your comment/reaction does indicate that you did
> NOT miss the point... ;-) so I'm satisfied. ;-) ;-)
>
> > For a start you will gratuitously offend the people
> > who spent their own time writing it (for no monetary
> > gain) if they happen to read your post.
>
> a) I spent quite a lot of my own time on boost.org
> and even contributed (for no monetary gain ;-))
> some of the stuff used in the current boost.thread.

OK. You don't seem particularly proud of the thing
you helped create though ;-)

> b) well, AFAIK, I am already on the "kill" list
> of W.Kempf! ;-)

And that is something to be proud of?

> > > I do not want to go into details,
> > > but for example, think of Apple/MAC and their
> > > "commercial"/official Pthreads impl once it become
> > > fully ready.
> >
> > I'm afraid I'm not familiar with this. Could you
> > explain what you mean?
>
> I mean roughly this:
> < from an e-mail I've sent to W.Kempf some time ago >

[snip email]

I meant I don't know about the Mac pthreads.
If it isn't (a) reasonably complete and very robust and
(b) available on a licence that permits compiler
and std lib vendors to sell it on as part of
their products, it cannot have much effect on C++
standardization. The information I found on it
after a quick Google was rather cagey on both
these points.

> > It could fly, although I notice it [Win32 pthreads] is


> > currently not a complete implementation
> > of pthreads.
>
> Only Microsoft could make it "complete", I mean
> FULL implementation of IEEE Std 1003.1-2001.

And why is that?

I'm trying to work out whether pthreads on non-Unix
platforms is like Java on multiple platforms (works
reasonably well) or more like COM on multiple
platforms (exists on non-Windows platforms, but
not widely used for whatever reasons, therefore we
assume it is really tied to the original platform).

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Alexander Terekhov

unread,
Mar 4, 2002, 2:16:14 PM3/4/02
to

Matthew Austern wrote:
>
> John Nagle <na...@animats.com> writes:
>
> > It's quite possible to make asynchronous
> > exceptions work, at least on most current processors.
> > Any CPU that can back out a page fault can do clean
> > exception handling. This was done in Ada years ago.
>
> The question isn't whether it's possible to implement asynchronous
> exceptions; it's whether such an implementation would be usable.
>
> Writing exception-safe code in C++ requires that you reason about
> which exceptions can occur at which points. With asynchronous
> exception handling, that's no longer possible; you can no longer
> write functions with the nothrow guarantee, or rely on the nothrow
> guarantee from functions that someone else wrote. I don't know
> how I could write reliable code without having that guarantee.

How about:

size_type basic_string::find(
const basic_string<charT,traits,Allocator>& str,
size_type pos = 0) const;

?

and just image that you could someday declare it as:

size_type basic_string::find(
const basic_string<charT,traits,Allocator>& str,
size_type pos = 0) const acsafe;

and compiler would help you to enforce the
async-cancel-safety of any "acsafe" function
impl (or async-cancel-region in general -- inside
any cancelable function/operation)...

regards,
alexander.

Alexander Terekhov

unread,
Mar 4, 2002, 2:42:45 PM3/4/02
to

Garry Lancaster wrote:
>
> Alexander Terekhov:
> > Technical aspects/functionality (current) of
> > "wrapping" aside, boost.thread just ignores
> > zillions lines of PORTABLE *C++* Pthread-ed
> > code (cancellation aside).
>
> It's portable between any two pthreads
> implementations that share the same de-facto
> pthreads-C++ binding, since there is no standard
> pthreads-C++ binding.

I think that the "de-facto pthread-C++ binding"
is this:

http://groups.google.com/groups?as_umsgid=37401A7B.222265F0%40zko.dec.com

"From: Dave Butenhof (bute...@zko.dec.com)
Subject: Re: Thread Cancellation and C++ Exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Newsgroups: comp.programming.threads
Date: 1999/05/17
...
As other replies have already said, the interactions
of C++ and POSIX are undefined, because neither formally
recognizes the existance of the other. Due to the close
similarity between C++ and C,
you're usually OK, as long as you stay away from
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the non-C aspects of C++, like exceptions and objects."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And, from my another c.l.c++.mod article:

http://groups.google.com/groups?as_umsgid=32B66F3B.2F1C%40zko.dec.com

From: Dave Butenhof (bute...@zko.dec.com)
Subject: Re: c++ trouble...
^^^^^^^^^^^
Newsgroups: comp.programming.threads
View: Complete Thread (8 articles) | Original Format
Date: 1996/12/17
^^^^^^^^^^

Otto Lind wrote:
> > The standard specifically requires that you treat these names as macros
> > expanding so that the push opens a block and the pop closes that block.
> > They MUST always be paired, at the same lexical scope.
>
> Just curious, Is the standard a "C POSIX" standard? Is there anything in
> it to address other language specific issues?

That is exactly the point. POSIX.1 is, specifically and exclusively, a
"C Language" binding. There is also a POSIX.5 series, which is "Ada
Language" bindings, and a POSIX.9 series, which is "FORTRAN Language"
bindings. There are no "C++ Language" bindings to POSIX, nor has there
been any serious proposal of which I'm aware -- certainly none have
gotten so far as a PAR (essentially a POSIX working group charter). Why?
Most likely because C++ is "close enough" to C that POSIX.1 works, even
though a native C++ binding would be easier to use and more flexible.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Using POSIX.1 cleanup handlers in C++ is absurd. Cancellation should be
made to invoke C++ object destructors, at an absolute minimum, instead.
Optionally, one might want to be able to use catch to finalize a Cancel
exception -- allowing the program to recover and continue. (While, in
most cases, a program should always reraise a cancel so the thread can
terminate, there are a few legitimate needs for a true exception-based
implementation.) But ANSI C doesn't have exceptions, or destructors, so
POSIX.1 invented cleanup handlers instead. And, because there's no
requirement (other than logic and reason) that a system's C++ compiler
and POSIX.1c implementation be integrated in any sane way, many C++
programmers (and anyone who wants to write fully portable code)
is stuck with the lowest common denominator."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> The whole point of standardization is to achieve
> a greater degree of portability than that. OK,
> pthreads could be a good starting point, but
> let's look at all the options.

OK, fine. What are the options?

> Garry Lancaster:
> > > > > I believe boost::thread is more portable.
>
> Alexander Terekhov:
> > > > I don't think so. It is just a POOR re-invention
> > > > (I would even call/label it as "FORK") of things/
> > > > projects like pthread-win32 with a thin object layer
> > > > added on top of it.
> > >
> > > I don't think shouting that it is poor is constructive.
> >
> > Boldface formatting "just" adds *emphasis". If you
> > consider it as "shouting" generally/altogether (or as
> > just silly annoyance preventing/disturbing "matured"
> > readers from reading by outline) that's your choice.
>
> I believe it's commonly known as shouting. If I'm
> wrong I apologise.

No apologies needed and/or wanted... just a bit more
tolerance and perhaps a couple or so of smiles. ;-)

> > But your comment/reaction does indicate that you did
> > NOT miss the point... ;-) so I'm satisfied. ;-) ;-)
> >
> > > For a start you will gratuitously offend the people
> > > who spent their own time writing it (for no monetary
> > > gain) if they happen to read your post.
> >
> > a) I spent quite a lot of my own time on boost.org
> > and even contributed (for no monetary gain ;-))
> > some of the stuff used in the current boost.thread.
>
> OK. You don't seem particularly proud of the thing
> you helped create though ;-)

Well, sort of.

> > b) well, AFAIK, I am already on the "kill" list
> > of W.Kempf! ;-)
>
> And that is something to be proud of?

Proud/not proud.. what's the point of asking
these questions? I've explained my position/
views, that's it.

[...]


> > > It could fly, although I notice it [Win32 pthreads] is
> > > currently not a complete implementation
> > > of pthreads.
> >
> > Only Microsoft could make it "complete", I mean
> > FULL implementation of IEEE Std 1003.1-2001.
>
> And why is that?

Because a lot of stuff actually need to be implemented
inside "system calls", think of scheduling options,
for example. Also, e.g. "manual" CondVar-win32 sucks
because it requires either locking across context
switches OR making scheduling decisions, etc, etc...

> I'm trying to work out whether pthreads on non-Unix
> platforms is like Java on multiple platforms (works
> reasonably well) or more like COM on multiple
> platforms (exists on non-Windows platforms, but
> not widely used for whatever reasons, therefore we
> assume it is really tied to the original platform).

Well pthreads is a standard portable interface for
threading with bindings available for C/ADA/... that's
it (but a lot of java VMs are simply layered on top
of pthreads, AFAIK).

regards,
alexander.

Alexander Terekhov

unread,
Mar 4, 2002, 4:09:54 PM3/4/02
to

Garry Lancaster wrote:
[...]

> > Perhaps
> > we just have a different understanding of what
> > post-/pre- c-/d-tors should do/what "problems"
> > should they address...
>
> Quite possibly, as I don't see a need for any of
> them. Let me expand on my first "Why?": why do
> you want post-ctors, pre-ctors, post-dtors and
> pre-dtors and how do you want them to work?

For example:

http://groups.google.com/groups?as_umsgid=3AA569BF.D1004E9%40web.de

Also, from some OLD e-mail to J.Kanze:
(I've somehow managed to loose/delete the
response to it; sorry, James)

[...poly/non-poly stuff...]

> It's sufficient to make your constructor parameters a special type;
> the constructor passes the address of the object to the argument
> object, and the destructor of the argument object calls your function.
> If the constructor would not otherwise take a parameter, make it take
> one of this type, and default it to a temporary instance. If it takes
> a parameter, use an implicite convertion to the initializer type.

you probably mean:

inline
GB_FieldArrayInitializer::GB_FieldArrayInitializer( GB_std::string
const& i )
: myInitValue( i )
, myArray( NULL )
{
}

inline
GB_FieldArrayInitializer::~GB_FieldArrayInitializer()
{
myArray->set( myInitValue ) ;
}

GB_FieldArray::GB_FieldArray( GB_FieldArrayInitializer const& init )
{
const_cast< GB_FieldArrayInitializer& >( init ).myArray = this ;
}

well,

a) how about all these pricey temps (performance impact)?
b) how about exception safety?
c) how about error-prone nature with respect to adding more derived
classes?
(on each level, each constructor should have a default argument with
temp instance..)
d) how about adding more levels of post-inits? destructors are called
in the opposite order (with respect to constructors) so that most
derived post-init will go BEFORE base post-init which is probably
(in many cases) would be incorrect..


regards,
alexander.

PS. i've started reading comp.lang.c++.mod really short time ago,
however,
during last several weeks the problem of poly.obj creation/destruction/
vf-dispatch was discussed/questioned number of times - e.g.
comp.lang.c++.mod
threads:

"Dispatching in constructors?"
"Calling virtual methods from constructors"

Alexander Terekhov

unread,
Mar 4, 2002, 6:22:52 PM3/4/02
to

Garry Lancaster wrote:
>
> Alexander Terekhov:
> > > > And, BTW, both need post-/pre-
> > > > c-/d-tors! ;-) ;-) (well, post-ctors only for
> > > > poor Java which lacks d-tors/RAI ;-)).
^^^^

>
> Garry Lancaster:
> > > Why? And once you do that why stop there? People
> > > will start asking for pre-pre-ctors and post-post-dtors.
[...]

Oh, forgot this one (nicely illustrates the
problem from Java perspective too, AFAICT):

http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1015.html

...
In practice, you rarely want to start a thread in a constructor, but I
illustrated in this way to make it fit on one slide. In any case,
aren't examples like this handled by requiring that parent thread make
available all variables to a new child thread? I'm newly confused
about where the problem is here.


The main contexts that demand the use of factory methods are ones
where you'd otherwise have something like:


class X {
final static Vector instances = new Vector();
X() {
instances.add(this);
}
}


class Y extends X {
final Field aField;
Y() {
// implicit super() call here.
aField = ...
}
}


The subclass has no way of controlling exposure. So you'd need to
rework this to use public static factory methods with private
constructors etc, which can itself be error-prone. Since you can't
inherit static methods, each subclass needs to invoke the proper
initialization methods:


class X {
final static Vector instances = new Vector();
protected void init() { instances.add(this); }
private X() {}


public static X newX() {
X x = new X();
x.init();
return x;
}
}


class Y extends X {
final Field aField;
private Y() { aField = ... }


public static Y newY() {
Y y = new Y();
y.init();
return y;
}
}


And there are many cases where you can't take this approach anyway. A
year or so ago, we discussed similar problems with the widespread use
of no-arg constructors plus init() methods in JavaBeans etc. Because
of JavaBeans instantiation conventions (normally using
Class.newInstance()), these classes rarely use factory methods that
would hide the object between default-construction and proper
initialization. Plus, they cannot usually use final fields because
the values only become known in init(). I still don't see any way for
people to deal with this except for synchronizing (at least parts of)
nearly all methods. This is not usually a big performance concern with
JavaBeans (they have other overhead anyway) but still a correctness
concern -- people often don't synchronize them because it is not
obvious that they need to.


-Doug
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel

Garry Lancaster

unread,
Mar 5, 2002, 10:59:23 AM3/5/02
to
Alexander Terekhov:

> > > Perhaps
> > > we just have a different understanding of what
> > > post-/pre- c-/d-tors should do/what "problems"
> > > should they address...

Garry Lancaster:


> > Quite possibly, as I don't see a need for any of
> > them. Let me expand on my first "Why?": why do
> > you want post-ctors, pre-ctors, post-dtors and
> > pre-dtors and how do you want them to work?
>
> For example:
>
> http://groups.google.com/groups?as_umsgid=3AA569BF.D1004E9%40web.de

>From that post:
> > struct A {
> > Thread thread;
> > A() : thread(this) { /*...*/ }
> > ~A() { /*...*/ }
> > virtual void run() = 0;
> > private:
> > post A() { thread.start( /*...*/); /*thread_start_routine calls
A::run*/}
> > pre ~A() { thread.join(); /*stop*/ }
> > };
> > class T {
> > public:
> > T() { /*...*/ }
> > ~T() { /*...*/ }
> > virtual void method() = 0;
> > private:
> > post T() { xyz.register( this ); }
> > pre ~T() { xyz.deregister( this ); }
> > };

For a start that doesn't mention pre-ctors or post-dtors.
Is it just the post-ctor and pre-dtor you want?

Sometimes you don't want the thread to start
immediately. You want to create it in a suspended
state and start it later on. The above class doesn't
permit that, by itself. Nonetheless auto-start is a
useful option, so I suspect you want both options in
your thread management system.

The class above is a bit confusing. Ideally
there would be separation between the class that
represents the worker thread and the one that a parent
thread can use to control the thread. Of course there
needs to be communication between the two, but placing
them in the same object is going too far in my opinion.
Java tries to achieve this separation with Thread and
Runnable. Whilst I don't necessarily advocate copying
the exact Java approach for C++ (it wouldn't work as
well in a non-garbage collected language), I think the
principle is sound.

You also say in the older post that you don't
want to use a wrapper class to solve the "problem"
because you find the solution involving the post-ctor
and pre-dtor simpler. Fair enough, but there are lots
of things that could be made slightly simpler by
extending the language.

It is not enough for a new feature to provide some
benefit, the level of benefit it provides must be
sufficiently compelling to outweigh the negative
effects of further complicating an already complex
language. And, in my opinion, this one isn't.

To return to one of my earlier questions ("why
stop there...?"), if we were to add post ctors, to
take just one example, so that a base class could
make some code run after all derived class ctors
had run, just how long do you think it would be
before someone wanted a post-post-ctor so that
a base class could make some code run after
all derived class post-ctors had run? You have
to stop somewhere. For simplicity, let's stop
exactly where we are now.

I had wondered from your earlier posts whether
pre- and post- ctors and dtors were, for some reason
that I had previously missed, essential for
multi-threading work. That certainly isn't the case.
They are really a separate subject.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Ray Blaak

unread,
Mar 5, 2002, 3:35:44 PM3/5/02
to
Ian Collins <i...@masuma.com> writes:
> Maybe some input form the Java or ADA community would help to identify
> the pros and cons of built in threads.

Well, I used to be an intense Ada programmer. Now I am an intense Java
programmer.

Pros: you can do threading, can do it portably, and you have language support
while doing so. Any library based thread models can only lag behind in ease of
use and integration with your language features.

Cons: can't think of any, off hand. Complexity to the compiler/runtime
environment, perhaps, but that to me is simply the cost of implementing
threading right once and for all.

Ah, I have one con: if you don't use threads then you would like to be able to
avoid the cost of threading. Ada does this more or less successfully. Java
does not: there is extra memory overhead for every object allocated to cover
the possibility that the object just might participate in synchronization.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.

Hans Aberg

unread,
Mar 5, 2002, 5:02:12 PM3/5/02
to
In article <ud6yjx...@telus.net>, Ray Blaak <bl...@telus.net> wrote:
>Ian Collins <i...@masuma.com> writes:
>> Maybe some input form the Java or ADA community would help to identify
>> the pros and cons of built in threads.

>Pros: you can do threading, can do it portably, and you have language support


>while doing so. Any library based thread models can only lag behind in ease of
>use and integration with your language features.

>Cons: can't think of any, off hand. Complexity to the compiler/runtime
>environment, perhaps, but that to me is simply the cost of implementing
>threading right once and for all.

>Ah, I have one con: if you don't use threads then you would like to be able to
>avoid the cost of threading.

Isn't it clear that C++ should have thread support, with a way to avoid
threads and their overhead if not needed?

I have an old (1989) book by Gehani & Roome, "The Concurrent C PL". Could
some thread experts please explain the relevance of that stuff for C++?

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

Garry Lancaster

unread,
Mar 5, 2002, 11:36:18 PM3/5/02
to
> > Alexander Terekhov:
> > > Technical aspects/functionality (current) of
> > > "wrapping" aside, boost.thread just ignores
> > > zillions lines of PORTABLE *C++* Pthread-ed
> > > code (cancellation aside).

Garry Lancaster:


> > It's portable between any two pthreads
> > implementations that share the same de-facto
> > pthreads-C++ binding, since there is no standard
> > pthreads-C++ binding.

Alexander Terekhov


> I think that the "de-facto pthread-C++ binding"
> is this:

>From another post:


> Due to the close
> similarity between C++ and C,
> you're usually OK, as long as you stay away from
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the non-C aspects of C++, like exceptions and objects."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In which case it's barely C++ at all. Which means
stating that there are "zillions lines of PORTABLE
*C++* Pthread-ed code", is a bit of a
misrepresentation.

Garry Lancaster:


> > > > It could fly, although I notice it [Win32 pthreads] is
> > > > currently not a complete implementation
> > > > of pthreads.

Alexander Terekhov:


> > > Only Microsoft could make it "complete", I mean
> > > FULL implementation of IEEE Std 1003.1-2001.
> >
> > And why is that?
>
> Because a lot of stuff actually need to be implemented
> inside "system calls", think of scheduling options,
> for example. Also, e.g. "manual" CondVar-win32 sucks
> because it requires either locking across context
> switches OR making scheduling decisions, etc, etc...

Win32 has a huge developer base and cannot be
ignored by C++, no matter how much Win32 ignores
C++. (And my impression is that MS are starting to
"ignore" C++ almost as much as they "ignore" Java -
it's C# or bust over at Redmond these days.)
We simply cannot alter the standard to specify a
threading system that cannot be fully implemented
on this platform.

This means that at best only a pthreads subset is suitable
for C++ standardisation. I guess we were already coming
to that conclusion anyway, what with the disagreement
over async exceptions, (at least I was) but this wraps it up.

> > I'm trying to work out whether pthreads on non-Unix
> > platforms is like Java on multiple platforms (works
> > reasonably well) or more like COM on multiple
> > platforms (exists on non-Windows platforms, but
> > not widely used for whatever reasons, therefore we
> > assume it is really tied to the original platform).
>
> Well pthreads is a standard portable interface for
> threading with bindings available for C/ADA/... that's
> it (but a lot of java VMs are simply layered on top
> of pthreads, AFAIK).

I wasn't querying which language bindings are
available, I was querying the usefulness/efficiency/
implementability of pthreads on non-Unix platforms.
You partially addressed that with your response
about the only-partial-implementability of pthreads
on Win32.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Hans Aberg

unread,
Mar 5, 2002, 11:38:46 PM3/5/02
to
In article <FcMf8.27620$Hg1.4...@news6-win.server.ntlworld.com>, "Garry
Lancaster" <glanc...@ntlworld.com> wrote:
>Alexander Terekhov:
>> ...
...

>If I understand you correctly, you are proposing
>that a thread could inject an exception into
>another thread.

The way it looks to me is that if one should design "safe" code or runtime
objects with respect to your favorite property X, where X = access or
runtime security, etc., then the trick seems to be design objects that
communicate with each other according to safe protocols. As going that the
full way in the form of runtime objects becomes too slow, given the
hardware architecture of todays computers, one can in a language like C++
supply a static analysis stripping out the components (runtime
interfacing) that actually are not used during runtime execution.

Now, if the idea is that one thread should somehow be able to manipulate
another thread in an "imperative" uncontrolled manner (not via a "safe"
protocol of that the thread recognizes), then that is an invitation to
write unsafe code.

In article <dilhenw...@isolde.research.att.com>, Matthew Austern
<aus...@research.att.com> wrote:

>John Nagle <na...@animats.com> writes:

>> It's quite possible to make asynchronous
>> exceptions work, at least on most current processors.
>> Any CPU that can back out a page fault can do clean
>> exception handling. This was done in Ada years ago.

>The question isn't whether it's possible to implement asynchronous
>exceptions; it's whether such an implementation would be usable.

>Writing exception-safe code in C++ requires that you reason about
>which exceptions can occur at which points. With asynchronous
>exception handling, that's no longer possible; you can no longer
>write functions with the nothrow guarantee, or rely on the nothrow
>guarantee from functions that someone else wrote. I don't know
>how I could write reliable code without having that guarantee.

So this is just one instance of the principle I mentioned above. One
encounters it too when trying to lock threads or bigger objects such as
databases, in order to keep the data consistent.

So if this the idea of "asynchronous exceptions", the question is why is
this feature useful? -- I mean, unless one has some very good examples
where the feature absolutely must be used, there is not point in adding
it.

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

---

Francis Glassborow

unread,
Mar 6, 2002, 12:58:51 PM3/6/02
to
In article <SY1h8.100563$Ah1.13...@news2-win.server.ntlworld.com>,
Garry Lancaster <glanc...@ntlworld.com> writes

>Win32 has a huge developer base and cannot be
>ignored by C++, no matter how much Win32 ignores
>C++. (And my impression is that MS are starting to
>"ignore" C++ almost as much as they "ignore" Java -
>it's C# or bust over at Redmond these days.)

Hmm... so why did the move Stan Lippman from C# to C++? And watch the
headlines for an upcoming very interesting addition to their C++ team.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

Alexander Terekhov

unread,
Mar 6, 2002, 12:59:12 PM3/6/02
to

Garry Lancaster wrote:
>
> > > Alexander Terekhov:
> > > > Technical aspects/functionality (current) of
> > > > "wrapping" aside, boost.thread just ignores
> > > > zillions lines of PORTABLE *C++* Pthread-ed
> > > > code (cancellation aside).
^^^^^^^^^^^^^^^^^^^^

>
> Garry Lancaster:
> > > It's portable between any two pthreads
> > > implementations that share the same de-facto
> > > pthreads-C++ binding, since there is no standard
> > > pthreads-C++ binding.
>
> Alexander Terekhov
> > I think that the "de-facto pthread-C++ binding"
> > is this:
>
> >From another post:
> > Due to the close
> > similarity between C++ and C,
> > you're usually OK, as long as you stay away from
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > the non-C aspects of C++, like exceptions and objects."
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> In which case it's barely C++ at all. Which means
> stating that there are "zillions lines of PORTABLE
> *C++* Pthread-ed code",

Did you miss "(cancellation aside)" bit above? ;-)

> is a bit of a misrepresentation.

Well, not "misrepresentation", I would classify it
(Butenhof's "stay away" bit) is a mild *exaggeration* ;-)
and/but it has SIGNIFICANT implications in the "real" world
too. For example, see this discussion:

http://sources.redhat.com/ml/pthreads-win32/2001/subjects.html#00143
("pthreads VCE: problem with destructor")

and the outcome:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/pthreads/NEWS?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=pthreads-win32
("Cleanup code default style. (IMPORTANT)")

> Garry Lancaster:
> > > > > It could fly, although I notice it [Win32 pthreads] is
> > > > > currently not a complete implementation
> > > > > of pthreads.
>
> Alexander Terekhov:
> > > > Only Microsoft could make it "complete", I mean
> > > > FULL implementation of IEEE Std 1003.1-2001.
> > >
> > > And why is that?
> >
> > Because a lot of stuff actually need to be implemented
> > inside "system calls", think of scheduling options,
> > for example. Also, e.g. "manual" CondVar-win32 sucks
> > because it requires either locking across context
> > switches OR making scheduling decisions, etc, etc...
>
> Win32 has a huge developer base and cannot be
> ignored by C++, no matter how much Win32 ignores
> C++. (And my impression is that MS are starting to
> "ignore" C++ almost as much as they "ignore" Java -
> it's C# or bust over at Redmond these days.)

;-)

And, BTW, C#/CLI "write-ups" ;-) are available here:

http://www.ecma.ch/ecma1/STAND/ecma-334.htm
http://www.ecma.ch/ecma1/STAND/ecma-335.htm
http://www.ecma.ch/ecma1/techrep/e-tr-084.htm

> We simply cannot alter the standard to specify a
> threading system that cannot be fully implemented
> on this platform.

Uhmm. Are you saying that MS simply cannot fully
implement it on their platform(s)?!

> This means that at best only a pthreads subset is suitable
> for C++ standardisation.

> I guess we were already coming
> to that conclusion anyway, what with the disagreement
> over async exceptions,

async.exceptions (async.cancel) IS a powerful and a
very useful tool, just take a look at Real-time Java
Spec stuff, for some examples, "justifications":

http://www.rtj.org
http://www.jcp.org/jsr/detail/001.jsp

regards,
alexander.

Alexander Terekhov

unread,
Mar 6, 2002, 1:00:00 PM3/6/02
to

Hans Aberg wrote:
[...]

> I have an old (1989) book by Gehani & Roome, "The Concurrent C PL". Could
> some thread experts please explain the relevance of that stuff for C++?

Well, how about some more (up-to-date and
EXCITING) stuff (in addition to your old C
book ;-))?

ftp://plg.uwaterloo.ca/pub/uSystem/

from "Announcement":

>> ANNOUNCEMENT <<

Version 4.9 of uC++ (pronounced micro-C++) is an extended C++ providing
light-weight concurrency on uniprocessor and multiprocessor computers
running
the UNIX operating system. uC++ extends C++ in somewhat the same way
that C++
extends C. The extensions introduce new objects that augment the
existing
control flow facilities and provide concurrency. uC++ provides both
direct and
indirect communication using the traditional routine call mechanism.
All
aspects of uC++ are statically type-checked. Furthermore, uC++ provides
mechanisms for precisely controlling the order in which requests are
serviced
and for postponing work on already-accepted requests.

Version 4.9 has:

. bug fixes, including improvements to the translator to handle the STL
. real-time support, including periodic, aperiodic and sporadic tasks,
plus
priority inheritance
. debugger support for KDB

There is also a concurrent debugger for uC++ 4.9, called KDB, which
allows
independent control of the user level threads (but it's broken at the
moment).


>> REQUIREMENTS <<

uC++ requires at least:

1. at least version egcs-1.1.2 or gcc-2.95.2. uC++ does NOT compile
using
other compilers.

2. at least version 3.79.1 of gmake, which is available by anonymous ftp
from
any FSF mirror site.


>> FTP SITE <<

Version 4.9 of uC++ can be obtained by anonymous ftp from the following
location (remember to set your ftp mode to binary):

plg.uwaterloo.ca:pub/uSystem/u++-4.9.tar.gz

The README file contains all the installation instructions. Good luck
and
happy concurrency.


>> PORTABILITY <<

uC++ comes configured to run on any of the following platforms:

sun-sparc-svr4 (solaris) (both single and multiple processor)
dec-alpha (both single and multiple processor)
sgi-mips-r4000 (both single and multiple processor)
sgi-mips-r3000 (single processor only)
ibm-rs6000 (single processor only)
hp-pa (single processor only)
pc-i386-linux (both single and multiple processor)


>> PAPERS <<

See http://plg.uwaterloo.ca/~usystem for additional information, papers
and
updates.


>> FUTURE <<

. concurrent exception handling capabilities in the next release
. database toolkit using memory mapping
. thread-level profiler

---

regards,
alexander.

Alexander Terekhov

unread,
Mar 6, 2002, 4:02:41 PM3/6/02
to

Garry Lancaster wrote:
[...]

> For a start that doesn't mention pre-ctors or post-dtors.
> Is it just the post-ctor and pre-dtor you want?

Yep. "post" for ctor(s) and "pre" for dtor.

> Sometimes you don't want the thread to start
> immediately. You want to create it in a suspended
> state and start it later on.

Yep (e.g. create multiple threads and start'em all
AFTER successful creation/registration/... or do NOT
start them at all IF something goes wrong (throws)
in the "init" phase, for example).

> The above class doesn't
> permit that, by itself. Nonetheless auto-start is a
> useful option, so I suspect you want both options in
> your thread management system.

Yep. http://www.terekhov.de/mythread.c

[...]


> To return to one of my earlier questions ("why
> stop there...?"), if we were to add post ctors, to
> take just one example, so that a base class could
> make some code run after all derived class ctors
> had run, just how long do you think it would be
> before someone wanted a post-post-ctor so that
> a base class could make some code run after
> all derived class post-ctors had run?

I guess you could just call some protected virtual
method(s) inside your base class post-ctor/pre-dtor.

> You have
> to stop somewhere. For simplicity, let's stop
> exactly where we are now.
>
> I had wondered from your earlier posts whether
> pre- and post- ctors and dtors were, for some reason
> that I had previously missed, essential for
> multi-threading work. That certainly isn't the case.
> They are really a separate subject.

Well, for some sort of "active objects" it is
not a separate subject, I guess. But, in general,
probably yes.

regards,
alexander.

Garry Lancaster

unread,
Mar 6, 2002, 4:44:43 PM3/6/02
to
> > >From another post:
> > > Due to the close
> > > similarity between C++ and C,
> > > you're usually OK, as long as you stay away from
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > the non-C aspects of C++, like exceptions and objects."
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Garry Lancaster:


> > In which case it's barely C++ at all. Which means
> > stating that there are "zillions lines of PORTABLE
> > *C++* Pthread-ed code",

Alexander Terekhov:


> Did you miss "(cancellation aside)" bit above? ;-)

No - I saw it, but it didn't seem relevant.

Or are you saying that cancellation is the only
reason that you can't use exceptions or objects
with pthreads?

Garry Lancaster:


> > We simply cannot alter the standard to specify a
> > threading system that cannot be fully implemented

> > on this [the Win32] platform.


>
> Uhmm. Are you saying that MS simply cannot fully
> implement it on their platform(s)?!

I guess they could if they wanted to. The point is
that there is no sign that they do want to *and* I suspect
the situation would be no different even if the C++ standard
required the changes. All that would happen is
that no-one would be able to fully implement
the C++ standard under Windows and MS C++
would become even more of a branch of standard
C++ than it already is. That would be a Bad
Thing (TM).

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Garry Lancaster

unread,
Mar 6, 2002, 4:53:43 PM3/6/02
to
Garry Lancaster:

> >Win32 has a huge developer base and cannot be
> >ignored by C++, no matter how much Win32 ignores
> >C++. (And my impression is that MS are starting to
> >"ignore" C++ almost as much as they "ignore" Java -
> >it's C# or bust over at Redmond these days.)

Francis Glassborow:


> Hmm... so why did the move Stan Lippman from
> C# to C++?

If he single-handedly saves the day that would be
great, but I'm pessimistic. Time will tell.

My thinking is that if a company the size of MS wanted
a standards compliant C++ compiler enough, they
would have one by now. If their internal compiler
team couldn't manage it, they could have got a fair
way by writing some very large cheques.

Despite everything I *like* the MS compiler, so I really
want them to sort it out. But in the 5 years from v6 to
v7 not a great deal seems to have changed. I've
heard that 7.1 will be much, much better, but I'm
running out of faith in those guys.

Unlike Visual Basic, MS's previous "favourite language",
C# is a serious attempt to do most of the things that
C++ does. If .NET catches on as MS hope it will, in
a few years time they will be in a position to heavily
restrict the running of native code on Windows. Result:
no real C++ anymore. Will this actually happen? Again,
time will tell.

> And watch the
> headlines for an upcoming very interesting addition to their C++ team.

Go on, spill the beans. You know you want to ;-)

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---

Francis Glassborow

unread,
Mar 6, 2002, 8:18:12 PM3/6/02
to
In article <N2wh8.62770$Hg1.10...@news6-win.server.ntlworld.com>,
Garry Lancaster <glanc...@ntlworld.com> writes

>> And watch the
>> headlines for an upcoming very interesting addition to their C++ team.
>
>Go on, spill the beans. You know you want to ;-)

Like any journalist, there are times when I am trusted with information
on a strictly confidential basis. Read my column in the next issue of C
Vu (actually it will be old news by then)

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---

t...@cs.ucr.edu

unread,
Mar 7, 2002, 12:33:07 PM3/7/02
to
Ray Blaak <bl...@telus.net> wrote:
[...]
: Any library based thread models can only lag behind in ease of

: use and integration with your language features.

Would you care to elaborate?

Tom Payne

Alexander Terekhov

unread,
Mar 7, 2002, 12:45:46 PM3/7/02
to

Garry Lancaster wrote:
[...]

> Alexander Terekhov:
> > Did you miss "(cancellation aside)" bit above? ;-)
>
> No - I saw it, but it didn't seem relevant.
>
> Or are you saying that cancellation is the only
> reason that you can't use exceptions or objects
> with pthreads?

http://groups.google.com/groups?as_umsgid=3C73CB8B.E764D3C6%40web.de
(see "yep (and pthread_exit too)" links as well)

> Garry Lancaster:
> > > We simply cannot alter the standard to specify a
> > > threading system that cannot be fully implemented
> > > on this [the Win32] platform.
> >
> > Uhmm. Are you saying that MS simply cannot fully
> > implement it on their platform(s)?!
>
> I guess they could if they wanted to. The point is
> that there is no sign that they do want to *and* I suspect
> the situation would be no different even if the C++ standard
> required the changes. All that would happen is
> that no-one would be able to fully implement
> the C++ standard under Windows and MS C++
> would become even more of a branch of standard
> C++ than it already is. That would be a Bad
> Thing (TM).

Ever heard of VMware (good old mainframe-class stuff
now available on commodity-class computers too)? Just
put all those "Bad Thing (TM)"s in couple of a virtual
machines/guests hosted by some really Good Thing (TM)
that is also used for the REAL programming/serious IT
stuff, in general. ;-)

regards,
alexander.

Chelly

unread,
Mar 10, 2002, 3:48:16 PM3/10/02
to
A few years ago I wrote a web page with my ideas on the matter of
asynchronous exceptions. I was interested in exploring the idea rather
than coming to conclusions as to its usefulness.

http://www.slack.net/~ant/cpp/asyncexcept.html

I hope this adds something useful to this lively discussion :)

Ray Blaak

unread,
Mar 11, 2002, 12:13:44 PM3/11/02
to
t...@cs.ucr.edu writes:
> Ray Blaak <bl...@telus.net> wrote:
> [...]
> : Any library based thread models can only lag behind in ease of
> : use and integration with your language features.
>
> Would you care to elaborate?

I mean this in only the trivial sense. A language-based thread model is no
worse than a library based one from a programmer's point of view, since it is
equivalent to doing the appropriate routine calls. However, the language-based
one can have custom syntax and can cooperate better with the compiler to be
more powerful in terms of expressivity.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.

---

Hans Aberg

unread,
Mar 11, 2002, 12:36:41 PM3/11/02
to
In article <not-for-mail-0...@tcnet01-55.austin.texas.net>,

postmast.ro...@iname.com (Chelly) wrote:
>A few years ago I wrote a web page with my ideas on the matter of
>asynchronous exceptions. I was interested in exploring the idea rather
>than coming to conclusions as to its usefulness.
>
> http://www.slack.net/~ant/cpp/asyncexcept.html
>
>I hope this adds something useful to this lively discussion :)

One idea that comes to my mind is that when throwing an exception, one is
in reality throwing a pair (exception, exception-handler-stack):

If the exception-handler-stack is not explicitly indicated, it is assumed
to be the "root", the one that the program comes with.

If threads are hooked up like on a parent-child tree, then the
exception-handler-stacks are hooked up similarly. If an exception is not
handled at the point where this stack branches, then other threads may be
killed off by the exception. This may sound wrong at first, but if say a
group of threads share memory, and one thread detects a memory error, then
all threads should be killed off sharing the same memory. So possibly, one
may need a mechanism telling which kinds of exceptions each thread should
be able to throw.

Then, under Mach (or so I recall), threads need to not be hooked up on a
parent-child tree, so the exception-handler-stack can be hooked up in even
more complicated manners.

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

---

Alexander Terekhov

unread,
Mar 11, 2002, 12:36:27 PM3/11/02
to
postmast.ro...@iname.com (Chelly) wrote in message news:<not-for-mail-0...@tcnet01-55.austin.texas.net>...

> A few years ago I wrote a web page with my ideas on the matter of
> asynchronous exceptions. I was interested in exploring the idea rather
> than coming to conclusions as to its usefulness.
>
> http://www.slack.net/~ant/cpp/asyncexcept.html

http://groups.google.com/groups?as_umsgid=user-1009992342430001%40aus-as3-150.io.com

: [...]
: First, let's consider it from the standpoint of throwing an exception
: asynchronously, with regard to the OS and threads.
:
: thread 1 // signal occurs here...
: thread 2 // ... or maybe here
: thread 3
:
: Which thread does exception get thrown in? Is it acceptable to have it
: thrown in what is essentially a random thread?

The short "answer" is:

async-signal-safety != async-cancel(exception)-safety != thread-safety

Details/Info[1]:

http://www.opengroup.org/onlinepubs/007904975/functions/sigwait.html

"RATIONALE

To provide a convenient way for a thread to wait for a
signal, this volume of IEEE Std 1003.1-2001 provides the
sigwait() function. For most cases where a thread has to
wait for a signal, the sigwait() function should be quite
convenient, efficient, and adequate.

However, requests were made for a lower-level primitive
than sigwait() and for semaphores that could be used by
threads. After some consideration, threads were allowed
to use semaphores and sem_post() was defined to be
async-signal and async-cancel-safe.

In summary, when it is necessary for code run in response
to an asynchronous signal to notify a thread, sigwait()
should be used to handle the signal. Alternatively, if the
implementation provides semaphores, they also can be used,
either following sigwait() or from within a signal handling
routine previously registered with sigaction()."

http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_04_03

"The sigevent structure is used by other POSIX.1 functions
that result in asynchronous event notifications to specify
the notification mechanism to use and other information needed
by the notification mechanism. IEEE Std 1003.1-2001 defines
only three symbolic values for the notification mechanism.
SIGEV_NONE is used to indicate that no notification is required
when the event occurs. This is useful for applications that use
asynchronous I/O with polling for completion. SIGEV_SIGNAL
indicates that a signal is generated when the event occurs.
SIGEV_NOTIFY[2] provides for "callback functions" for asynchronous
notifications done by a function call within the context of a new
thread. This provides a multi-threaded process a more natural means
of notification than signals. The primary difficulty with previous
notification approaches has been to specify the environment of the
notification routine.

One approach is to limit the notification routine to call
only functions permitted in a signal handler. While the list
of permissible functions is clearly stated, this is overly
restrictive.

A second approach is to define a new list of functions or
classes of functions that are explicitly permitted or not
permitted. This would give a programmer more lists to deal
with, which would be awkward.

The third approach is to define completely the environment
for execution of the notification function. A clear definition
of an execution environment for notification is provided by
executing the notification function in the environment of a
newly created thread."

http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_04.html

"Multi-threaded programs can use an alternate event notification
mechanism. When a notification is processed, and the sigev_notify
member of the sigevent structure has the value SIGEV_THREAD, the
function sigev_notify_function is called with parameter sigev_value.

The function shall be executed in an environment as if it were
the start_routine for a newly created thread with thread attributes
specified by sigev_notify_attributes. If sigev_notify_attributes is
NULL, the behavior shall be as if the thread were created with the
detachstate attribute set to PTHREAD_CREATE_DETACHED."

regards,
alexander.

[1] PDFs:

http://www.opengroup.org/publications/mem-online/c950/c950.pdf
http://www.opengroup.org/publications/mem-online/c951/c951.pdf
http://www.opengroup.org/publications/mem-online/c952/c952.pdf
http://www.opengroup.org/publications/mem-online/c953/c953.pdf
http://www.opengroup.org/publications/mem-online/c610/c610.pdf

Registration and free membership to get access:

http://www.opengroup.org/austin


[2] That should be "SIGEV_THREAD" (NOT "SIGEV_NOTIFY").

John Nagle

unread,
Mar 12, 2002, 2:06:30 PM3/12/02
to
Assuming you want to do this, let me suggest an approach
that leads to cleaner semantics.

Suppose we take the position that an asynchronous
exception can only occur at the following points:

-- Any non-inline call
-- Any loop-type statement (for, while, do)

In any program of finite size, one of those has to
happen reasonably soon.

As for implementation, there are several
possibilities:

- Flag test - the compiler generates a
test for the thread-termination flag at
every for, while, do, and call. Simple,
easy to do, and carries a performance
penalty.

- Breakpoint - when a thead is interrupted
("interrupted" here means something like a UNIX signal)
and asked to throw an exception, the thread is
stepped forward, as in a debugger, until the next
allowable throw point is reached, at which point
the exception is thrown. A (possibly large) table
of allowed throw points is needed. No speed penalty
until an exception is requested.

- Hardware - Flag test, as above, but with hardware
support. Consider for future CPUs if this feature
proves possible.

Note that this is less intrusive than the Ada
model, which allows machine-level exceptions that have
to happen RIGHT NOW, like hardware fault detection.

John Nagle
Animats

Herb Sutter

unread,
Mar 12, 2002, 2:09:24 PM3/12/02
to
On Wed, 6 Mar 2002 21:53:43 GMT, "Garry Lancaster"
<glanc...@ntlworld.com> wrote:
>My thinking is that if a company the size of MS wanted
>a standards compliant C++ compiler enough, they
>would have one by now.

Microsoft is (finally, and relatively recently) committed to producing a
100% conformant C++ compiler, meaning not only C++98, but also tracking the
evolving C++0x as it begins to form, and specifically support for key
community libraries. It won't all be in 7.1, but significant steps in that
direction will be. It's amazing what replacing one key internal
decision-maker a year or so ago will do to liberate a team that already
wanted to do the right thing.

I'm glad, because conformance to standards is important. You know it, and I
know it. That's why we hang out in this group and attend committee meetings.

>Despite everything I *like* the MS compiler, so I really
>want them to sort it out. But in the 5 years from v6 to
>v7 not a great deal seems to have changed. I've
>heard that 7.1 will be much, much better

I hope so. Time will tell.

Herb

---
Herb Sutter (www.gotw.ca)

Secretary, ISO WG21/ANSI J16 (C++) standards committee (www.gotw.ca/iso)
Contributing Editor, C/C++ Users Journal (www.cuj.com)

Check out "THE C++ Seminar" - Boston, March 2002 (www.gotw.ca/cpp_seminar)

Alexander Terekhov

unread,
Mar 12, 2002, 4:57:14 PM3/12/02
to

John Nagle wrote:
>
> Assuming you want to do this,

To do what? Form async-cancel-regions?

> let me suggest an approach
> that leads to cleaner semantics.

[...]

Personally, I am quite happy with "manual"
"semantics"[1] of

// arrange some clean up (fix up) if needed
// (should have PTHREAD_CANCEL_DEFERRED type
// active while doing this)
//...
pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS,&ct );
... // async-cancel-safe code/operations
pthread_setcanceltype( ct,&ct );

to form async-cancel-regions.

The only thing that I am missing is the compiler enforcement
of async-cancel-safety inside async-cancel-regions...

> Note that this is less intrusive than the Ada
> model, which allows machine-level exceptions that have
> to happen RIGHT NOW, like hardware fault detection.

Uhmm, what do you mean?

http://www-users.cs.york.ac.uk/~andy/lrm95/09_08.htm

"(5) When the execution of a construct is aborted (including
that of a task_body or of a sequence_of_statements), the
execution of every construct included within the aborted
execution is also aborted, except for executions included
within the execution of an abort-deferred operation; the
execution of an abort-deferred operation continues to
completion without being affected by the abort; the
following are the abort-deferred operations: ..."

"(21) If an assignment operation completes prematurely
due to an abort, the assignment is said to be disrupted;
the target of the assignment or its parts can become
abnormal, and certain subsequent uses of the object can
be erroneous, as explained in 13.9.1."

Also, you might want to take a look at pthreads-win32:
(the way how it implements C++ exception-based async-cancel)

http://sources.redhat.com/pthreads-win32

regards,
alexander.

[1]
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_setcancelstate.html

"RATIONALE

The pthread_setcancelstate() and pthread_setcanceltype()
functions control the points at which a thread may be
asynchronously canceled. For cancelation control to be
usable in modular fashion, some rules need to be followed.

An object can be considered to be a generalization of a
procedure. It is a set of procedures and global variables
written as a unit and called by clients not known by the
object. Objects may depend on other objects.

First, cancelability should only be disabled on entry to
an object, never explicitly enabled. On exit from an object,
the cancelability state should always be restored to its
value on entry to the object.

This follows from a modularity argument: if the client
of an object (or the client of an object that uses that
object) has disabled cancelability, it is because the
client does not want to be concerned about cleaning up
if the thread is canceled while executing some sequence
of actions. If an object is called in such a state and
it enables cancelability and a cancelation request is
pending for that thread, then the thread is canceled,
contrary to the wish of the client that disabled.

Second, the cancelability type may be explicitly set
to either deferred or asynchronous upon entry to an
object. But as with the cancelability state, on exit
from an object the cancelability type should always be
restored to its value on entry to the object.

Finally, only functions that are cancel-safe may be
called from a thread that is asynchronously cancelable."

Alexander Terekhov

unread,
Mar 12, 2002, 7:00:44 PM3/12/02
to

Alexander Terekhov wrote:
[...]
> [...poly/non-poly stuff...]

Heck! I just can't resist; "details" are here:

http://groups.google.com/groups?as_umsgid=3C8CBE40.4530411B%40web.de
http://groups.google.com/groups?as_umsgid=3C8DED28.3154017%40web.de

regards,
alexander.

David Butenhof

unread,
Mar 13, 2002, 12:07:33 PM3/13/02
to
Matthew Austern wrote:

> John Nagle <na...@animats.com> writes:
>
>> It's quite possible to make asynchronous
>> exceptions work, at least on most current processors.
>> Any CPU that can back out a page fault can do clean
>> exception handling. This was done in Ada years ago.
>
> The question isn't whether it's possible to implement asynchronous
> exceptions; it's whether such an implementation would be usable.
>
> Writing exception-safe code in C++ requires that you reason about
> which exceptions can occur at which points. With asynchronous
> exception handling, that's no longer possible; you can no longer
> write functions with the nothrow guarantee, or rely on the nothrow
> guarantee from functions that someone else wrote. I don't know
> how I could write reliable code without having that guarantee.

POSIX supports asynchronous cancelability (the ability for one thread to
"asynchronously inject an exception" into another thread) for historical
convenience. Asynchronous cancelability isn't necessary (at best it's a
minor performance boost), and it's almost impossible to use even in
straight POSIX/C. (The only POSIX functions that can legally be called with
async cancelability are the functions that disable async cancelability,
disable cancelability entirely, and post a pending cancel to another
thread. The latter is a "stupid thread trick" that never belonged in the
standard and cannot rationally be justified.)

Cancellation really operates synchronously, and that's the only form truly
and broadly supported by the standard. With synchronous ("deferred")
cancelability (the default for all threads), another thread can do no more
than asynchronously POST a request, much like a pending signal mask in
UNIX. But that's just data, and data that's not explicitly visible in the
standard interfaces. The thread itself, at well defined execution points
(particularly blocking calls) tests the state of that pending cancel
flag and, if necessary and appropriate, raises the cancel exception. That
means all deferred cancellation points, as defined by POSIX/UNIX and any
additional C++ points, would be tagged as being able to throw the cancel
exception.

There's no need for a "C++ POSIX thread binding" to support async
cancelability. In fact, I would encourage the standards committee to
disallow async cancelability. It's a bad idea, it's not well supported or
particularly usable (nor useful) even for POSIX and C, and as pointed out
here distinctly does not fit into the C++ exception model.

/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/

David Butenhof

unread,
Mar 13, 2002, 12:07:56 PM3/13/02
to
Hans Aberg wrote:

> In article <not-for-mail-0...@tcnet01-55.austin.texas.net>,
> postmast.ro...@iname.com (Chelly) wrote:
>>A few years ago I wrote a web page with my ideas on the matter of
>>asynchronous exceptions. I was interested in exploring the idea rather
>>than coming to conclusions as to its usefulness.
>>
>> http://www.slack.net/~ant/cpp/asyncexcept.html
>>
>>I hope this adds something useful to this lively discussion :)
>
> One idea that comes to my mind is that when throwing an exception, one is
> in reality throwing a pair (exception, exception-handler-stack):
>
> If the exception-handler-stack is not explicitly indicated, it is assumed
> to be the "root", the one that the program comes with.
>
> If threads are hooked up like on a parent-child tree, then the
> exception-handler-stacks are hooked up similarly. If an exception is not
> handled at the point where this stack branches, then other threads may be
> killed off by the exception. This may sound wrong at first, but if say a
> group of threads share memory, and one thread detects a memory error, then
> all threads should be killed off sharing the same memory. So possibly, one
> may need a mechanism telling which kinds of exceptions each thread should
> be able to throw.
>
> Then, under Mach (or so I recall), threads need to not be hooked up on a
> parent-child tree, so the exception-handler-stack can be hooked up in even
> more complicated manners.

This isn't an issue for POSIX threads.

POSIX threads do not have parent-child relationships. All threads are
peers, and as nearly equal as possible. (The only real exception is that a
return from most threads is equivalent to pthread_exit() while a return
from the initial thread [main()] is equivalent to exit(), terminating the
process.)

DCE did try to build this sort of hierarchy for RPC relationships; an
exception that terminated an RPC server routine would propagate to the stub
routine in the client (caller). This proved REALLY annoying; but of course
in that case exception support was primitive (C macros) and we were
propagating the exception (sans stack context) across address spaces and
even architectures/operating systems.

DCE also established that converting hardware errors into exceptions was a
mistake; though one that could be at least partly addressed with
better/deeper exception support. The problem is that a SIGSEGV, for
example, indicates a problem with the address space. There's not much hope
that you can really recover from this, but exception conversion implies
that you can. As you say, shutting down the process quickly and with
minimum perturbation is best, so the problem can be analyzed. Eventually
DCE returned to the original idea that a SIGSEGV just dumps core and
terminates.

On the other hand, other operating systems like OpenVMS, which grew up with
exceptions from the start, do report memory errors as exceptions. Process
termination occurs only when/if the memory exception propagates to the base
of the stack... but it still terminates the process rather than an
individual thread. An eventual core dump at that point may be less useful,
though, since the offending stack has probably been unwound.

Finally, a minor note on Mach. Yes, Mach had threads, but they're really
barebones and primitive. (Remember, "Mach" is just the central core of an
operating system, not a whole operating system.) Like nearly every other
widespread threading system, Mach threads lack any parental relationships
(except that each Mach thread is connected to a single Mach task context).
Mach "exceptions" aren't exceptions in the C++/Ada sense; rather, they're a
special kind of IPC message directed to a distinct communications port
that's automatically assigned to each thread.

/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/

---

Alexander Terekhov

unread,
Mar 13, 2002, 3:03:30 PM3/13/02
to

David Butenhof wrote:
[...]

> POSIX threads do not have parent-child relationships. All threads are
> peers, and as nearly equal as possible. (The only real exception is that a
> return from most threads is equivalent to pthread_exit() while a return
> from the initial thread [main()] is equivalent to exit(), terminating the
> process.)

How about future threads-aware C++0x with "void{*} thread::main(...)"
*alternative* (optional) w.r.t the current "exceptional" main()?

> DCE also established that converting hardware errors into exceptions was a
> mistake; though one that could be at least partly addressed with
> better/deeper exception support. The problem is that a SIGSEGV, for
> example, indicates a problem with the address space. There's not much hope
> that you can really recover from this, but exception conversion implies
> that you can.

Nope.
http://groups.google.com/groups?as_umsgid=3C75280D.571C0C0A%40web.de

"'9 If no matching handler is found in a program, the function
terminate() is called; whether or not the stack is unwound
before this call to terminate() is implementation-defined
(15.5.1). ' ^^^^^^^^^^^^^^^^^^^^^^

Personally, I would really prefer: stack is NOT unwound,
as the standard requirement with a note: PROGRAMMERS, do
your emergency inter-process cleanup in terminate_handlers!"

> As you say, shutting down the process quickly and with
> minimum perturbation is best, so the problem can be analyzed. Eventually
> DCE returned to the original idea that a SIGSEGV just dumps core and
> terminates.
>
> On the other hand, other operating systems like OpenVMS, which grew up with
> exceptions from the start, do report memory errors as exceptions. Process
> termination occurs only when/if the memory exception propagates to the base
> of the stack... but it still terminates the process rather than an
> individual thread. An eventual core dump at that point may be less useful,
> though, since the offending stack has probably been unwound.

So, why do you then "propagate to the base of the stack"?!

Just to find out that there is actually NO matching hander
present?

Uhmm.. Looking at:

http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH9MBTE.PDF

for example, I see nothing that could/would prevent to
find this out PRIOR to "stack-unwinding". So, again,
I guess I'm just missing something. :( :(

regards,
alexander.

Alexander Terekhov

unread,
Mar 13, 2002, 8:59:51 PM3/13/02
to

David Butenhof wrote:
[...]

> POSIX supports asynchronous cancelability (the ability for one thread to
> "asynchronously inject an exception" into another thread) for historical
> convenience.

Uhmm. Rationale section(s) and C953 volume
do NOT put/present it this way, AFAICT.

> Asynchronous cancelability isn't necessary (at best it's a
> minor performance boost), and it's almost impossible to use even in
> straight POSIX/C. (The only POSIX functions that can legally be called with
> async cancelability are the functions that disable async cancelability,
> disable cancelability entirely, and post a pending cancel to another
> thread. The latter is a "stupid thread trick" that never belonged in the
> standard and cannot rationally be justified.)

OK, fine. You probably mean:

"2.9.5.4 Async-Cancel Safety

2356 The pthread_cancel(), pthread_setcancelstate(),
and pthread_setcanceltype() functions are defined to
2357 be async-cancel safe.
2358 No other functions in this volume of IEEE Std 1003.1-2001
are required to be async-cancel-safe."

But, sorry, what does this have to do with *MY* functions?

Are you saying that it's almost impossible to write correct
and valid async-cancel-safe functions (code-region) in POSIX/C,
C++ aside, for a moment?!

[...]


> There's no need for a "C++ POSIX thread binding" to support async
> cancelability. In fact, I would encourage the standards committee to
> disallow async cancelability.

Well, if I could, I would encourage the standards committee to
think a bit in the direction of const-like async-cancel-safety
*enforcement* mechanism added to the C++0x language...

> It's a bad idea, it's not well supported or
> particularly usable (nor useful) even for POSIX and C, and as pointed out
> here distinctly does not fit into the C++ exception model.

What exactly "does not fit into the C++ exception model"?

I fail to see the point/reason... perhaps I'm just missing
something. :(

regards,
alexander.

David Butenhof

unread,
Mar 14, 2002, 8:40:45 AM3/14/02
to
Alexander Terekhov wrote:

> But, sorry, what does this have to do with *MY* functions?
>
> Are you saying that it's almost impossible to write correct
> and valid async-cancel-safe functions (code-region) in POSIX/C,
> C++ aside, for a moment?!

Yes. At least, anything "interesting". If you create or hold resources, you
can write "async-cancel safe" code only by DISABLING either cancellation
(entirely) or async cancelability across that region of code.

You can't call malloc() or free(), for example, with async cancelability
enabled. If you did, you wouldn't be able to tell whether your memory had
been allocated -- or whether it had truly been freed. Unless of course THEY
were made async-cancel safe... which could be done only by disabling async
cancel so they could determine reliably what resources THEY owned.

Interrupting execution at arbitrary points, asynchronously, makes recovery
difficult.

The only INTENDED purpose was so you could write a compute-bound loop, that
held no resources, without making constant calls to pthread_testcancel(),
and still have it responsive to cancel requests. OK, great; but, honestly,
"big deal". It's rarely useful, mostly misused, and complicates everything
about using and describing cancellation. We'd be better off without it.

We did it in CMA not because we saw a real need, but "because we could".
Experience teaches, if nothing else, that "because we could" is a really
bad excuse for just about anything...

> [...]
>> There's no need for a "C++ POSIX thread binding" to support async
>> cancelability. In fact, I would encourage the standards committee to
>> disallow async cancelability.
>
> Well, if I could, I would encourage the standards committee to
> think a bit in the direction of const-like async-cancel-safety
> *enforcement* mechanism added to the C++0x language...

Sure, I would encourage them to think about it enough to realise that it's
impossible in general and impractical and pointless even in specific cases
where it's possible.

>> It's a bad idea, it's not well supported or
>> particularly usable (nor useful) even for POSIX and C, and as pointed out
>> here distinctly does not fit into the C++ exception model.
>
> What exactly "does not fit into the C++ exception model"?
>
> I fail to see the point/reason... perhaps I'm just missing
> something. :(

Because, as someone said, C++ is designed with the expectation that
exceptions arise synchronously and under full language control, via throw.
There are no asynchronous exceptions. Adding them is not trivial. I argue
that it's not useful. I'm NOT going to argue that this shouldn't be
considered; just that I know what the outcome should be. ;-)

/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/

---

Hans Aberg

unread,
Mar 14, 2002, 11:38:35 AM3/14/02