Concurrency

[David Rasmussen]

Are there any indicators for

1) whether the C++ commitee will include
concurrency in the next standard
2) what it will look like (Java, ZThreads, etc.)

/David

[Alf P. Steinbach]

On Wed, 21 Jan 2004 01:30:59 +0100, David Rasmussen <da*************@gmx.net> wrote:

Are there any indicators for

1) whether the C++ commitee will include
concurrency in the next standard
2) what it will look like (Java, ZThreads, etc.)

Probably Boost Threads, if anything. Check out
<url: http://www.boost.org/libs/thread/doc/index.html>.
Alternatively pthreads.

But I hope such support isn't added this time.

Not having thread handling standardized reflects the situation that
the standard library isn't designed for multithreading, that 'volatile'
is next to unusable, and so on. In particular, there is the thorny
issue of exceptions in threads. And the somewhat larger picture of
exception importance levels, the next to unusable exception hierarchy,
and handling of multiple exceptions and exceptions in destructors,
which if addressed needs to be compatible and integrated with threads.

[David Harmon]

On Wed, 21 Jan 2004 01:30:59 +0100 in comp.lang.c++, David Rasmussen
<da*************@gmx.net> was alleged to have written:

Are there any indicators for

1) whether the C++ commitee will include
concurrency in the next standard
2) what it will look like (Java, ZThreads, etc.)

The newsgroup for the discussion of the C++ standardization process and
what the C++ committee will do is comp.std.c++ (please read first before
posting.)
http://groups.google.com/groups?scor...mp.std.c%2B%2B

[David Rasmussen]

Alf P. Steinbach wrote:

Probably Boost Threads, if anything. Check out
<url: http://www.boost.org/libs/thread/doc/index.html>.
Alternatively pthreads.

Pthreads? Surely, if anything, it will be an OOP
approach.

Not having thread handling standardized reflects the situation that
the standard library isn't designed for multithreading, that 'volatile'
is next to unusable, and so on.
Still, many incarnations of the standard library
exist that cope well with concurrency? It's not
impossible.
In particular, there is the thorny
issue of exceptions in threads.
It works reasonably well in Java, doesn't it?
And the somewhat larger picture of
exception importance levels, the next to unusable exception hierarchy,
and handling of multiple exceptions and exceptions in destructors,
which if addressed needs to be compatible and integrated with threads.

I'm not sure these problems are greater than the
problem of not having a standardized concurrency
model in the language.

But I see now that my discussion is off topic, so:
sorry :)

/David

[Alexander Terekhov]

David Rasmussen wrote:

Alf P. Steinbach wrote:

Probably Boost Threads, if anything. Check out
<url: http://www.boost.org/libs/thread/doc/index.html>.
Alternatively pthreads.

Pthreads? Surely, if anything, it will be an OOP
approach.

It will be both Boost.Thread-like stuff in <thread> and 100%
pthreads compatible stuff in <cthread>. I bet a bottle of
"Tisserand", Alf. ;-)

Not having thread handling standardized reflects the situation that
the standard library isn't designed for multithreading, that 'volatile'
is next to unusable, and so on.

Still, many incarnations of the standard library
exist that cope well with concurrency? It's not
impossible.

In particular, there is the thorny
issue of exceptions in threads.

It works reasonably well in Java, doesn't it?

Java's EH is totally brain-damaged.

regards,
alexander.

[David Rasmussen]

Alexander Terekhov wrote:

Java's EH is totally brain-damaged.

Why?

/David

[Alexander Terekhov]

David Rasmussen wrote:

Alexander Terekhov wrote:

Java's EH is totally brain-damaged.

Why?

Because you can't have throw() code in Java, to begin with.

regards,
alexander.

[David Rasmussen]

Alexander Terekhov wrote:

Because you can't have throw() code in Java, to begin with.

I'm not sure I follow. A small example comparing
C++ and Java, showing your point?

/David

[Alexander Terekhov]

David Rasmussen wrote:

Alexander Terekhov wrote:

Because you can't have throw() code in Java, to begin with.

I'm not sure I follow.

http://google.com/groups?selm=3D09E7...7350A%40web.de
A small example ...

http://google.com/groups?selm=3D0A3F...1F08F%40web.de

regards,
alexander.

[David Rasmussen]

Alexander Terekhov wrote:

http://google.com/groups?selm=3D09E7...7350A%40web.de

A small example ...

http://google.com/groups?selm=3D0A3F...1F08F%40web.de

None of these links meant anything to me. Maybe I
lacked the context. But I'll take your word for
it. All I know is that what little concurrent
programming I did in Java with exceptions
involved, worked flawlessly.

/David

[Alexander Terekhov]

David Rasmussen wrote:
[...]

None of these links meant anything to me. Maybe I
lacked the context. But I'll take your word for
it.
Don't take my word. Click on "View: Complete Thread"
and study the context.
All I know is that what little concurrent
programming I did in Java with exceptions
involved, worked flawlessly.

Miracles Happen To Believers, you know.

regards,
alexander.

[David Rasmussen]

Alexander Terekhov wrote:

David Rasmussen wrote:
[...]

None of these links meant anything to me. Maybe I
lacked the context. But I'll take your word for
it.
Don't take my word. Click on "View: Complete Thread"
and study the context.

Will do, when I get the time. But I really wish that a simple example
could be given, not just an esoteric one.

Miracles Happen To Believers, you know.

I am not a Java believer. I like C++ much more. But the few times I had
to use Java and had to do something concurrently and with exceptions, I
had met no limitations.

/David

[Jorge Rivera]

I did not find anything particularly useful in those links.

Without pretending to understand every detail of that particular thread,
I will give you my opinion...

Unknown errors might happen at anytime. The fact that the documentation
states that at any point in time the Java VM can crash does not imply
that exceptions in threads is broken in Java and the VM is "brain-damaged".

Think about what happens in any Unix environment when you get a SIGPIPE
or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
would prevent those errors, as they are outside the boundaries of the
language, and the behavios of the process at that point is undefined.

I think that in general, the Java thread and exception models are well
designed and implemented.

Jorge L

Alexander Terekhov wrote:

David Rasmussen wrote:

Alexander Terekhov wrote:

Because you can't have throw() code in Java, to begin with.

I'm not sure I follow.

http://google.com/groups?selm=3D09E7...7350A%40web.de

A small example ...

http://google.com/groups?selm=3D0A3F...1F08F%40web.de

regards,
alexander.

[David Rasmussen]

Jorge Rivera wrote:

I think that in general, the Java thread and exception models are well
designed and implemented.

They are certainly better than not having a standard at all. And it is
not like C++ is a perfect language which must not be befouled with
unperfect things. C++ is full of ugly solutions, primarily stemming from
C. I am not saying that we shouldn't care about the quality of the
language, quite the opposite. But I don't see the harm (quite the
opposite), in standardizing concurrency in some reasonable way. When we
get more knowledge about the choices made, we can change the language
later. That's how it is done now with other features. What separates
concurrency from all the other half-hearted hybrid features of C++?

/David

[Alexander Terekhov]

Jorge Rivera wrote:
[...]

Think about what happens in any Unix environment when you get a SIGPIPE
or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
would prevent those errors, as they are outside the boundaries of the
language, and the behavios of the process at that point is undefined.

The behavior of the PROCESS ta that point is fully defined in the
"standard Unix environment" (which is nothing but extended ISO C
environment). Some implementation even convert synchronous signals
to implementation-defined exceptions (that's because the C++ std
says that C++ "might not work" in signal handlers, I guess ;-) )
and you can catch them using C++ catch(...). You might want to
take a look at "is catch(...) safe" c.l.c++.mod thread.

regards,
alexander.

[Jerry Coffin]

In article <4p*****************@twister.nyroc.rr.com>,
jo*****@rochester.rr.com says...

I did not find anything particularly useful in those links.

That's what you should expect with Alexander -- he specializes in
posting references that don't really refer to the question at hand. If
you're willing to spend enough time chasing, you'll almost always find
something relevant -- but it'll just be another instance of him making
the same unsupported statement he's made in the current thread.

The reality is that Alexander is a smart guy and he knows a lot about
concurrent programming. Most of the statements he makes are correct,
but his actual contribution to the average thread is a negative one --
following the links he posts is normally just about the slowest, most
inefficient possible way of learning anything (except that Alexander
posts a LOT of stupid links, as if making the same unsupported assertion
before acts as proof when he makes it again). You'd be more likely to
learn something by choosing a book blindfolded, and then reading it in
the hope that it might accidentally be related to something you care
about.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jorge Rivera]

Jerry Coffin wrote:

In article <4p*****************@twister.nyroc.rr.com>,
jo*****@rochester.rr.com says...

I did not find anything particularly useful in those links.

That's what you should expect with Alexander -- he specializes in
posting references that don't really refer to the question at hand. If
you're willing to spend enough time chasing, you'll almost always find
something relevant -- but it'll just be another instance of him making
the same unsupported statement he's made in the current thread.

The reality is that Alexander is a smart guy and he knows a lot about
concurrent programming. Most of the statements he makes are correct,
but his actual contribution to the average thread is a negative one --
following the links he posts is normally just about the slowest, most
inefficient possible way of learning anything (except that Alexander
posts a LOT of stupid links, as if making the same unsupported assertion
before acts as proof when he makes it again). You'd be more likely to
learn something by choosing a book blindfolded, and then reading it in
the hope that it might accidentally be related to something you care
about.

Thanks for the insight... lol

Jorge L

[Jorge Rivera]

Alexander Terekhov wrote:

Jorge Rivera wrote:
[...]

Think about what happens in any Unix environment when you get a SIGPIPE
or SIGSEGV. It is very unlikely that ANY mechanism implemented in C++
would prevent those errors, as they are outside the boundaries of the
language, and the behavios of the process at that point is undefined.

The behavior of the PROCESS ta that point is fully defined in the
"standard Unix environment" (which is nothing but extended ISO C
environment). Some implementation even convert synchronous signals
to implementation-defined exceptions (that's because the C++ std
says that C++ "might not work" in signal handlers, I guess ;-) )
and you can catch them using C++ catch(...). You might want to
take a look at "is catch(...) safe" c.l.c++.mod thread.

Thanks, I will verify that to understand better.

However, the point I was trying to make is that there are system
conditions in which *ANY* language might fail, regardless of code
correctness and exception mechanisms, therefore I don't think that Java
is particularly fickle because it could 'crash at any time'.

Yes, the Java VM could fatally fail, and so could any mechanisms in the
C++ language.

regards,
alexander.