WaitForMultipleObjects is bad? So how to program without it?
Michael Podolsky
I was told many times (and have seen the same oppinions on this news
group)
that WaitForMultipleObjects is generally non necessary and there is no
need in such function in unix multithread programming.
So here I present some common patterns of using of
WaitForMultipleObjects in Win32 programming. Please explain how the
same may be done without WaitForMultiple... on Win32 or on Unix
pthreads.
1) Application shutdown. To do it, I usually have "ManualEvent"
(stateful, broadcasting) and signal it. Every part of code that does
waiting, waits for this event also, so each thread may be asked to
abandone itself. Now - how can I design my code in unix to abandone
the wait for a conditional variable in unix? Probably the answer would
be that I should set some 'shutdown'-flag and then signal that
conditional variable so that resumed thread will test this shutdown
flag. But that simply means that the part of code that initiates
shutdown should know EVERY conditional variable in the application.
And should know related mutex for each such conditional variable. Bad,
isn't it? Or may be I have missed some point?
2) Besides, if my unix program waits for a mutex (and not for condvar)
- how should I make that thread to abandone its work on shutdown?
3) Suppose I have some shared data and some Win32 event that is used
to signal about that data update. Here again I have something to wait,
while I may also want to wait other sources of the same type (shared
data and event). You may say that my interfaces are poorly designed,
but what if that interfaces are used to communicate between different
processes? (so call back notification supposes using of smth heavy
like corba).
Hope, you understand that I am not Win32 fanatic and do not want to
provoke a sort of flame. Yet my practice was on Win32 and it predicts
my current way of thinking (that I would like to extend).
Regards, Michael
Arnold Hendriks
> Hello all and especially unix guys that hate "brain damaged windows"
'A thread that uses a wait function with no time-out interval may cause
the system to become deadlocked.' (WaitMultipleObjects SDK page).
Erhm, huh? applications deadlocking the entire system? This one once hit
me pretty badly on a NT4 system, making it almost unusable until I killed
some random apps in the taskmanager.
But anyway, it's mostly a matter of taste. Eg, I personally prefer CVs over
events because CVs are stateless, while an event has a state that is the
result of a different state somewhere else in the program. I consider
duplication of such state information ugly, so that's my personal reason
for preferring CVs. (BTW, I code on both WinNT and linux..)
> I was told many times (and have seen the same oppinions on this news
> group)
> that WaitForMultipleObjects is generally non necessary and there is no
> need in such function in unix multithread programming.
Well, the call isn't there, and as far as I can tell, no Win32 application
is unimplementable on UNIX, so one probably can do without. Of course,
you can just consider select() to be a WaitForMultipleObjects() in disguise.
> 1) Application shutdown. To do it, I usually have "ManualEvent"
> (stateful, broadcasting) and signal it. Every part of code that does
[shutdown flag]
> And should know related mutex for each such conditional variable. Bad,
> isn't it? Or may be I have missed some point?
That's basically how it's done internally. But you don't have to implement
it yourself, you can just use pthread cancellation as an asynchronous
mean to tell a thread to quit.
> 2) Besides, if my unix program waits for a mutex (and not for condvar)
> - how should I make that thread to abandone its work on shutdown?
pthread_mutex_lock isn't a cancellation point, so it will wait. but when
the other threads are shutting down, whatever kept your first thread waiting
will be unlocked, and the waiting thread will continue to run and quit at
its first cancellation point.
But a win32 event-induced cancel isn't immediate either.
> 3) Suppose I have some shared data and some Win32 event that is used
> to signal about that data update. Here again I have something to wait,
> while I may also want to wait other sources of the same type (shared
> data and event). You may say that my interfaces are poorly designed,
> but what if that interfaces are used to communicate between different
> processes? (so call back notification supposes using of smth heavy
> like corba).
This will depend on your particular design. In a boss/worker model, all
tasks are a state machine, and threads just pick up tasks. When they wait
for such an event, they relinquish their current task, and the boss will
reassign the task to a thread whenever any of the requested events happen.
This boss could use a CV or a select() with pipes to deal with the events.
Dedicated threads can be used to convert other types of external notifications
into CV signals or write()s.
Admittedly, this doesn't work that well if you use a different model than
boss/worker, although you can then still use a dedicated thread to convert
external signals to something you can work with. I haven't worked with any
other threading model as extensive as with boss/worker, so someone else would
have to shed some light on that.
Incidentally, for boss/worker models, I find the win32 I/O completion port
driven designs to be quite compatible with a unix select() design. It allows
a quite portably code design with high SMP performance, though it may be
over-engineering for your purposes.
> Hope, you understand that I am not Win32 fanatic and do not want to
> provoke a sort of flame. Yet my practice was on Win32 and it predicts
> my current way of thinking (that I would like to extend).
For me, I moved from win32 first to linux next, and generally only try to
use the simplest of synchronisation mechanisms - and stick to what the win32
and linux threading APIs have in common. Win32 pthreads is too complex for
my needs, as I have no need for things such as cancellation - developing
only server software generally makes boss/worker the simplest approach, and
you don't need cancellation with that.
I found CVs easier to use than Win32 events, so I added my own simple layer
on top of win32 events to be a little more like CVs. For one it's because
I prefer stateless objects, and CVs also seem to have better semantics for
working with multiple threads - which again, helps with boss/worker :-)
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Alexander Terekhov
Michael Podolsky wrote:
>
> Hello all and especially unix guys that hate "brain damaged windows"
FWIW, I'm sort-of 'mainframe' guy and almost hate "brain-damaged-too unix" ;-)
apart from POSIX Threads, of course.
> I was told many times (and have seen the same oppinions on this news group)
> that WaitForMultipleObjects is generally non necessary and there is no need
> in such function in unix multithread programming.
Have you also seen the following nice write-up/opinion:
http://groups.google.com/groups?selm=slrn7hiau9.1q3.kaz%40ashi.FootPrints.net
(I especially like "...president of the United States." bit ;-))
<?>
Anyway, please do me a favor and send an e-mail to David.B...@hp.com
with very, very politely and thoughtfully [etc.] formulated question wrt
the implied meaning of "can be nice" remark that can be found here:
http://groups.google.com/groups?selm=3CF4B135.4B0C5A8%40web.de
("Well, respected c.p.t. poster also wrote this: ...")
TIA. ;-) ;-)
regards,
alexander.
Patrick TJ McPhee
Michael Podolsky <mich...@identify.com> wrote:
% So here I present some common patterns of using of
% WaitForMultipleObjects in Win32 programming. Please explain how the
% same may be done without WaitForMultiple... on Win32 or on Unix
% pthreads.
%
% 1) Application shutdown.
Cancellation.
% 3) Suppose I have some shared data and some Win32 event that is used
% to signal about that data update. Here again I have something to wait,
% while I may also want to wait other sources of the same type (shared
% data and event).
One approach is to use a single condition variable to signal the
waiting thread. For instance, you hand the data over, whatever it is,
by putting a pointer on a queue. The processing threads wait on the
queue (at root, they're waiting on a single condition variable).
If you have to wait on sources of information outside the process,
you probably need a dedicated thread to do that, but it depends on
what mechanisms are used to signal availability. A lot of things
in Unix act like file handles, and you can use poll() to multiplex.
I think the main complaints against waitformultipleobjects have to
do with limitations of the implementation (how many things can you
wait for, how can you tell which objects have signalled), rather
than the concept of multiplexing waits.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Bil Lewis
This is an interesting, very complex question. At least the question
I infer you *meant* to ask.
The answer to the question you *actually* asked is simple: Call exit().
As long as you're going to do a "dirty" shutdown anyway, why bother with
all that fancy waiting junk?
Oh! You didn't realize you were doing a dirty shutdown?
Surprise!
Consider: You told us (implicitly) that you have some thread that
owns a mutex and it's going to die in the middle of a critical section.
(You said you need to have a thread that is waiting for a mutex
abandon its wait, implying the owner has died.)
You have no idea what state your data is in when it dies, so it must
be assumed corrupted. Bummer.
The broader question I assume you meant to ask "How can I cleanly shutdown
a program asynchronisly?" (sp?) is indeed tough. You've said that every module
of your program has to know about shutdown request. (Well, everything
that ever waits, but that could be everything.) Do you *really* want to
do that?
Probably not.
Almost certainly you only want your top-level modules to deal with shutdown.
They then have to be responsible for making it possible for low-level
modules to wakeup and complete their work, so that the high-level module
can do the shutdown.
I'm not saying it's easy to do this. But I am saying that IF you do
this, your program will run correctly 100% of the time.
Currently, from what you've said, I infer that your program runs correctly
99.99% of the time.
And that last 0.01% can be a real unpleasant surprise.
-Bil
Michael Podolsky
> Brain damage comments are caused by SDK comments like this:
> 'A thread that uses a wait function with no time-out interval may cause
> the system to become deadlocked.' (WaitForMultipleObjects SDK page).
Well, let's put apart brain damaged interfaces/implementations and
brain damaged documentation. (besides, that SDK page explains detaily
what is meant by "system deadlock" in case of WaitFor... so you can
know where you are enabled to do it with infinite timeout and where
not)
> But anyway, it's mostly a matter of taste. Eg, I personally prefer CVs over
> events because CVs are stateless, while an event has a state that is the
> result of a different state somewhere else in the program. I consider
> duplication of such state information ugly, so that's my personal reason
> for preferring CVs. (BTW, I code on both WinNT and linux..)
Good explanation. Still one never (nearly) needs to test explicitly
the state of Win32 event. Win32 event just has a property that its
fact of signaling is never loosed because of race condition. Actually,
win32 automatic event is exactly bynary semaphore, nothing more (apart
"pulse"). Well, I am ready to agree that manual event is rather hard
to deal with.
> Well, the call isn't there, and as far as I can tell, no Win32 application
> is unimplementable on UNIX, so one probably can do without.
Of course. But the question is - "how do they do it in a proper way?".
>Of course,
> you can just consider select() to be a WaitForMultipleObjects() in disguise.
Do you mean that I can wait for multiple sync objects with 'select'
???
> > 1) Application shutdown. To do it, I usually have "ManualEvent"
> > (stateful, broadcasting) and signal it. Every part of code that does
> [shutdown flag]
> > And should know related mutex for each such conditional variable. Bad,
> > isn't it? Or may be I have missed some point?
> That's basically how it's done internally. But you don't have to implement
> it yourself, you can just use pthread cancellation as an asynchronous
> mean to tell a thread to quit.
OK. Cancellation mechanics is OK for shutdown, but it is too specific
for some other cases. Suppose that I don't need to shutdown thread
completely, but just need to abandone its part (consider smth like
thread that renders picture with specific resolution for GUI. If
resolution is changed - I need to ask my thread to abandone current
rendering and restart it with new resolution.) Such thing can't be
done with cancelation mechanics. And of course, I don't want to finish
my old thread and to start a new one in this case -- that is ugly.
> > 2) Besides, if my unix program waits for a mutex (and not for condvar)
> > - how should I make that thread to abandone its work on shutdown?
> pthread_mutex_lock isn't a cancellation point, so it will wait. but when
> the other threads are shutting down, whatever kept your first thread waiting
> will be unlocked, and the waiting thread will continue to run and quit at
> its first cancellation point.
Now consider a case when my thread waits for a mutex that is owned by
another process. :-)
>> 3) [...]
> [...]
As for idea of using dedicated threads to convert external events to
internal condvars signalling - I find it appropriate. Still, such
dedicated thread should know what condwar should it signal and what
mutex should it acquire before signaling (and what if there are many
condvars and mutexes?). Such a design (where information about
condvars and mutexes is spreaded to many parts of code) does not seem
proper for me. In Win32 I can just wait for as many things (well, #64
bound) as I need in any place without any help from other parts of
code.
Regards, Michael
Michael Podolsky
> Michael Podolsky wrote:
> % 1) Application shutdown.
> Cancellation.
OK. Now suppose you need to abandone some calculation (which includes
waiting on condvars) that is done by some thread or subsystem of
threads without canceling it(them). Smth with the same problems I
mentioned for shutdown but now you can't use cancellation.
More details (also including some discussion about #3 as far) are in
my answer to http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF8&oe=UTF8&selm=adsj5q%24epc%241%40news.btcnet.nl
(sorry for not addressnig that my message directly -- I don't see it
currently in goolge)
> I think the main complaints against waitformultipleobjects have to
> do with limitations of the implementation (how many things can you
> wait for, how can you tell which objects have signalled), rather
> than the concept of multiplexing waits.
Well, your oppinion is much more moderate comparing the opinions I've
heard from unix guys. I have been simply told that there no any need
for things like WaitForMultiple in unix.
Regards, Michael
Michael Podolsky
> Michael,
>
> Consider: You told us (implicitly) that you have some thread that
> owns a mutex and it's going to die in the middle of a critical section.
Well, I've told that I want to abandone wait function. I've also told
that a thread may be ASKED :-) to abandone itself. Anyway, surely, I
didn't mean to abort a thread without resource releasing and
invariants recovering.
> The broader question I assume you meant to ask "How can I cleanly shutdown
> a program asynchronisly?" (sp?) is indeed tough. You've said that every module
> of your program has to know about shutdown request. (Well, everything
> that ever waits, but that could be everything.) Do you *really* want to
> do that?
Well, you are right, I definitely presented invalid model when I told
about a way program should shutdown (through total, non-hierarchy
notification, as I said). Of course, you are right, the things are
more complex and some hierarchic (at least) notification should be
used (while I formally can still try to think about some correct model
that gets total notification as I said :-).
Actually, my intention was to check another, more technical and local
aspect
- the very implementation of thread shutdown (or, as more complex
variation, cancelation of some part of work that is done inside a
thread without it full shutdown).
Regards, Michael
Michael Podolsky
> FWIW, I'm sort-of 'mainframe' guy and almost hate "brain-damaged-too unix" ;-)
> apart from POSIX Threads, of course.
Oh, yeah, that "brain damaged EC EBM" (IBM 360)? :-)
> Have you also seen the following nice write-up/opinion:
> http://groups.google.com/groups?selm=slrn7hiau9.1q3.kaz%40ashi.FootPrints.net
Yes, I've seen. But I suppose, OS or standard library should provide
some useful set of operations, not the basic minimal one.
> (I especially like "...president of the United States." bit ;-))
Well, the good part of proper programming is anybody can use a
feature, even if it was developed for the president. )))
> Anyway, please do me a favor and send an e-mail to David.B...@hp.com
Well, I have not got your idea (together with abbreviations you use).
Could you please explain it by e-mail? KOI-8 is OK. ))
Regards, Michael
Patrick Doyle
>
>Now consider a case when my thread waits for a mutex that is owned by
>another process. :-)
Pthread mutexes can't be owned by another process; only by another
thread.
--
--
Patrick Doyle
doy...@eecg.toronto.edu
Michael Podolsky
> Michael Podolsky wrote:
> >Now consider a case when my thread waits for a mutex that is owned by
> >another process. :-)
>
> Pthread mutexes can't be owned by another process; only by another
> thread.
Surely it can. See pthread_mutexattr_setpshared
Alexander Terekhov
Michael Podolsky wrote:
[...]
> As for idea of using dedicated threads to convert external events to
> internal condvars signalling - I find it appropriate. Still, such
> dedicated thread should know what condwar should it signal and what
> mutex should it acquire before signaling (and what if there are many
> condvars and mutexes?).
http://groups.google.com/groups?selm=3B0BA709.973337EB%40web.de
(Subject: Re: Question about POSIX Cancellation mechanims)
regards,
alexander.
Alexander Terekhov
Michael Podolsky wrote:
>
> Alexander Terekhov wrote:
>
> > FWIW, I'm sort-of 'mainframe' guy and almost hate "brain-damaged-too unix" ;-)
> > apart from POSIX Threads, of course.
>
> Oh, yeah, that "brain damaged EC EBM" (IBM 360)? :-)
I personally have *NEVER* [thus far] heard of 'brain damaged'
things... that were STOLEN BY THE >>KGB<< [especially in the
'golden' Soviet era]. ;-) ;-)
regards,
alexander.
Arnold Hendriks
while]
mich...@identify.com (Michael Podolsky) wrote in message news:<8cc5e356.02060...@posting.google.com>...
> >Of course,
> > you can just consider select() to be a WaitForMultipleObjects() in disguise.
> Do you mean that I can wait for multiple sync objects with 'select'
> ???
No, but that at many places where you would use WaitForMultipleObjects
in
win32, you can often more-or-less use UNIX select(). I didn't mean it
as
a drop-in replacement, but just to indicate that similair
functionality does
exist in Unix.
Eg, where you wait for one of multiple events to raise with Win32's
WaitForMultipleObjects, you can use a similair design with pipe()s and
select() - the select() can wait on multiple pipe read ends, and you
can
satisfy the wait by writing something on the write end. They're not
complete
replacements, but if I'd convert a Win32 piece of code using
WaitForMultipleObjects to Unix, I'd probably use a select() in that
spot
(though unidirectional pipes are perhaps a bit heavier than events)
> > That's basically how it's done internally. But you don't have to implement
> > it yourself, you can just use pthread cancellation as an asynchronous
> > mean to tell a thread to quit.
> OK. Cancellation mechanics is OK for shutdown, but it is too specific
> for some other cases. Suppose that I don't need to shutdown thread
> completely, but just need to abandone its part (consider smth like
> thread that renders picture with specific resolution for GUI. If
> resolution is changed - I need to ask my thread to abandone current
> rendering and restart it with new resolution.) Such thing can't be
> done with cancelation mechanics. And of course, I don't want to finish
> my old thread and to start a new one in this case -- that is ugly.
Depending on your code, signalling may be another option. You could
send
a user-defined signal to the thread that you want to stop, and the
signal
handler inside that thread sets a flag. You shouldn't need to use CVs
for
that kind of unidirectional signalling, but I might be missing
something here.
You may even be able to just siglongjmp() outside the signal handler
and
outside the rendering loop to immediately stop it, but that depends on
the
signal-safety of the code inside the thread code.
> > > 2) Besides, if my unix program waits for a mutex (and not for condvar)
> > > - how should I make that thread to abandone its work on shutdown?
> > pthread_mutex_lock isn't a cancellation point, so it will wait. but when
> > the other threads are shutting down, whatever kept your first thread waiting
> > will be unlocked, and the waiting thread will continue to run and quit at
> > its first cancellation point.
> Now consider a case when my thread waits for a mutex that is owned by
> another process. :-)
Pthread mutexes, as long as no special attributes are set, are more
similair to Win32's critical sections than to Win32's mutexes. But the
other process ought
to give up its mutex as soon as possible (unless you're deadlocked,
but all is
lost then anyway). Pthread's mutexes are supposed to be light and
fast, and
the programmer is expected to lock them as short as possible. Their
design
isn't as well suited for long-held locks, but of course nothing stops
you
then from building your own mutex type :)
Patrick Doyle
>Patrick Doyle wrote:
>
>> Pthread mutexes can't be owned by another process; only by another
>> thread.
>
>Surely it can. See pthread_mutexattr_setpshared
I stand corrected. Thanks.
Michael Podolsky
> Depending on your code, signalling may be another option. You could
> send
> a user-defined signal to the thread that you want to stop, and the
> signal
> handler inside that thread sets a flag. You shouldn't need to use CVs
> for
> that kind of unidirectional signalling, but I might be missing
> something here.
>
> You may even be able to just siglongjmp() outside the signal handler
> and
> outside the rendering loop to immediately stop it, but that depends on
> the
> signal-safety of the code inside the thread code.
Yeah! But even if one would develop application level code to be
signal safe
( let me consider this to be rather untrivial task after hundreeds of
pages about C++ exception safety published in last years ), I don't
see a way to deliver async signal to the particular thread. I can't
allocate separate signal for each thread I may want to "interrupt" and
I can't share same signal for broadcasting to each thread of interest.
> Pthread mutexes, as long as no special attributes are set, are more
> similair to Win32's critical sections than to Win32's mutexes. But the
> other process ought
> to give up its mutex as soon as possible (unless you're deadlocked,
> but all is
> lost then anyway). Pthread's mutexes are supposed to be light and
> fast, and
> the programmer is expected to lock them as short as possible. Their
> design
> isn't as well suited for long-held locks, but of course nothing stops
> you
> then from building your own mutex type :)
Well, the problem is - mutexes and condvars togeter constitute the
basis for syncronisation development (alternatively called "monitor").
When I use this basis, I can't cancel thread because mutex_lock is not
cancelation point. And if I use my own implementation of mutex (say,
based on semaphore) for interprocess syncronisation, I can't use
condvar togeter with it and I don't have a trivial way to implement my
own condvar. Besides, it's strange practice to reimplement the whole
set of sync objects just in order to gain possibility of thread
cancelation (that still does not give possibility to abandone a part
of calculations inside thread).
Regards,
Michael
Bil Lewis
It might be useful to go back and think about what you're *really*
trying to do. (I believe you're putting the cart before the horse.)
You have a thread which is performing a calculation, and for some
reason you decide that you no longer need that calculation. The
easiest thing is to allow the calculation to complete and then
throw away the result. But that might take a lot of time/resources.
So you want it to stop early. Cancellation is just one method of
doing this. And it's generally not the best way either (because
it's so hard to do correctly).
But sometimes it's nice to use cancellation. It has the potential
of stopping the calculation sooner, saving you time/resources. But
all the details you're thinking about are just that -- details.
They are virtually never important. And in your case, they are
certainly not important.
(It's that old straw -- if you have to ask, the answer is "no".)
So... it's good to think about this. Keep thinking. But it's not
useful for you in your program, so don't freak out about it.
Program correctness. THAT is worth freaking out about. Saving a few
milliseconds? nah.
-Bil
Michael Podolsky
> I can't share same signal for broadcasting to each thread of interest.
Sorry, this my statement was incorrect.
So the option of using signals together with siglongjmp seems now correct for me.
Thanks,
Michael
Patrick TJ McPhee
Michael Podolsky <mich...@identify.com> wrote:
% Well, the problem is - mutexes and condvars togeter constitute the
% basis for syncronisation development (alternatively called "monitor").
% When I use this basis, I can't cancel thread because mutex_lock is not
% cancelation point.
So, the thread acts on the cancel somewhere other than the mutex lock.
If you have unacceptably long waits for mutexes to the point that you
can't cancel a thread, then you have bigger problems. Note that even
when you cancel a condition wait, the mutex will be reaquired before
the wait function returns.
Michael Podolsky
> It might be useful to go back and think about what you're *really*
> trying to do.
Just to understand how they write code without WaitForMultiple in
unix/pthreads. This particularly includes questions and problems that
have been presented.
> You have a thread which is performing a calculation, and for some
> reason you decide that you no longer need that calculation. The
> easiest thing is to allow the calculation to complete and then
> throw away the result. But that might take a lot of time/resources.
> So you want it to stop early. Cancellation is just one method of
> doing this. And it's generally not the best way either (because
> it's so hard to do correctly).
I agree. Cancelation is too special to be used for "abandone"
notifications. It eventually finishes a thread (while we may want to
abandone just a part of calculations) and it asks for too
sophisticated coding.
> But all the details you're thinking about are just that -- details.
Correct.
> They are virtually never important. And in your case, they are
> certainly not important.
Hmmm... my case (and the case of this topic as i see it) is - talking
about technical details.
> So... it's good to think about this. Keep thinking. But it's not
> useful for you in your program, so don't freak out about it.
> Program correctness. THAT is worth freaking out about.
Well, I do not see a way to write correct programs, while I do not
able at all to implement/solve some set of simple, trivial, local
problems.
All the issues that I have raised are solved on Win32 exactly in this
way - trivially and easily. This is not to say that Win32 is "great"
but to ask - what is the native way, unix programmers solve these
problems.
> Saving a few milliseconds? nah.
Well, my case is definitely not to present some special case (picture
rendering) and to argue if I should abandone calculations or continue
them even if I do not need a result.
I am interested in getting general solution for WaitForMultiple...
problem (or for "making abandone" problem as its small part) and I
have presented "picture rendering" just for illustration. Anyway,
taking the real situation I had in my practice, "image rendering"
could take minutes.
Regards,
Michael
Bil Lewis
> All the issues that I have raised are solved on Win32 exactly in this
> way - trivially and easily. This is not to say that Win32 is "great"
> but to ask - what is the native way, unix programmers solve these
> problems.
Ah! Well you got a pile of ways to write programs correctly and
efficiently, so I won't add to that. The one important bit that
seems to have been missed is that Win32 is NOT doing what you're
assuming it's doing.
Most particularly it is leaving a gaping hole in your program where
data corruption can creep in. I've seen this many times on many
platforms. The one thing that Win32 does which is particularly bad,
is lure the programmer into thinking that s/he is doing something
safely when it ain't so.
As long as you want a "dirty" solution, it's just as easy in PThreads
as Win32. If you want to do it "correctly" it's hard on both.
-Bil
PS: "abandone" dropped the final "e" back around 1640. At least in
the US.
Alexander Terekhov
Michael Podolsky wrote:
[...]
> > You have a thread which is performing a calculation, and for some
> > reason you decide that you no longer need that calculation. The
> > easiest thing is to allow the calculation to complete and then
> > throw away the result. But that might take a lot of time/resources.
> > So you want it to stop early. Cancellation is just one method of
> > doing this. And it's generally not the best way either (because
> > it's so hard to do correctly).
It's no harder to do correctly than to write 'basic' exception-safe
code. Oh, BTW, you can't really do it AT ALL in Java. Java's exceptions
model is BUSTED, 'interruption' including [almost everything is busted
in Java - memory mode, 'monitors', etc.]
> I agree. Cancelation is too special to be used for "abandone"
> notifications. It eventually finishes a thread (while we may want to
> abandone just a part of calculations) and it asks for too
> sophisticated coding.
Uhmm. Interesting. Could you please elaborate [lack of standard
catch-'ability' w.r.t. thread-cancel exceptions aside, please].
regards,
alexander.
Arnold Hendriks
> Michael Podolsky wrote:
> [...]
>> > You have a thread which is performing a calculation, and for some
>> > reason you decide that you no longer need that calculation. The
>> > easiest thing is to allow the calculation to complete and then
>> > throw away the result. But that might take a lot of time/resources.
>> > So you want it to stop early. Cancellation is just one method of
>> > doing this. And it's generally not the best way either (because
>> > it's so hard to do correctly).
> It's no harder to do correctly than to write 'basic' exception-safe
exceptions) are synchronous, and the number of places where an exception
can be thrown are known and limited. If a line of code is unable to
generate an exception, it will never do so. However, asynchronous signals
can interrupt at any moment, and you will have to explicitly block them
in sections of code where you cannot deal with them - the help you get
from the language is much less.
For example, malloc() probably doesn't have to worry about exceptions at
all, but likely won't be able to deal with an asynchronous signal which
causes a signal handler to longjmp() out of malloc().
Imagine a world where you could always throw an exception outside a
signal handler, what a wonderful and happy place it would be :)
Eric D Crahen
> Oh, BTW, you can't really do it AT ALL in Java. Java's exceptions
> model is BUSTED,
What exactly are you claiming is busted about Java's exceptions?
- Eric
http://www.cse.buffalo.edu/~crahen
Alexander Terekhov
Eric D Crahen wrote:
>
> On Wed, 12 Jun 2002, Alexander Terekhov wrote:
>
> > Oh, BTW, you can't really do it AT ALL in Java. Java's exceptions
> > model is BUSTED,
>
> What exactly are you claiming is busted about Java's exceptions?
...busted about Java's exceptions:
http://groups.google.com/groups?selm=3C73AB86.99B8CBE0%40web.de
...busted about C++'s exceptions:
http://groups.google.com/groups?selm=3C77AFCB.481D2587%40web.de
regards,
alexander.
Alexander Terekhov
Arnold Hendriks wrote:
[...]
> For example, malloc() probably doesn't have to worry about exceptions at
> all, but likely won't be able to deal with an asynchronous signal which
> causes a signal handler to longjmp() out of malloc().
Yes; and this is exactly what async-cancel-safety is all about:
http://groups.google.com/groups?selm=3C73AB86.99B8CBE0%40web.de
(see "b) the presence of async.exceptions *without*...")
regards,
alexander.
Arnold Hendriks
> Arnold Hendriks wrote:
> [...]
>> For example, malloc() probably doesn't have to worry about exceptions at
>> all, but likely won't be able to deal with an asynchronous signal which
>> causes a signal handler to longjmp() out of malloc().
> Yes; and this is exactly what async-cancel-safety is all about:
the basic exception safety guarantee (at least a C++ concept, I don't know
of other languages to which it is relevant), which is of course completely
different (and a lot simpler) than making code async-cancel safe.
Alexander Terekhov
Arnold Hendriks wrote:
[...]
> >> For example, malloc() probably doesn't have to worry about exceptions at
> >> all, but likely won't be able to deal with an asynchronous signal which
> >> causes a signal handler to longjmp() out of malloc().
> > Yes; and this is exactly what async-cancel-safety is all about:
> With "'basic' exception-safety" I presumed you referred to code implementing
> the basic exception safety guarantee (at least a C++ concept, I don't know
> of other languages to which it is relevant), which is of course completely
> different (and a lot simpler) than making code async-cancel safe.
Sorry. I meant 'essential' [a fundamental, irreducible constituent of a whole]
w.r.t. exception-safety and programming in general -- 'transactional' approach.
But async-cancel-safe routines [or the ones which use async-cancel-regions
internally] should also provide either basic or strong exception-safety
guarantee [and nothrow isn't async-cancel-safe by definition ;-)]. BTW, that
[in general] has really little to do with exact mechanism of control transfer
[way to report 'errors'] -- the same principles apply even without using some
sort of 'throw-expressions'.
regards,
alexander.
Michael Podolsky
> The one important bit that seems to have been missed is that Win32 is NOT doing what you're assuming it's doing.
This sounds very, very surprising for me.
> Most particularly it is leaving a gaping hole in your program where
> data corruption can creep in. I've seen this many times on many
> platforms.
Could you please clarify last sentences? Could you provide an example
that illustrates the mentioned problem of gaping hole with data
corruption?
> The one thing that Win32 does which is particularly bad,
> is lure the programmer into thinking that s/he is doing something
> safely when it ain't so.
It must be really, really bad thing if such a hole really happens
because of Win32 implementation/documentation.
Regards,
Michael
Michael Podolsky
> Michael Podolsky wrote:
> [...]
> > > You have a thread which is performing a calculation, and for some
> > > reason you decide that you no longer need that calculation. The
> > > easiest thing is to allow the calculation to complete and then
> > > throw away the result. But that might take a lot of time/resources.
> > > So you want it to stop early. Cancellation is just one method of
> > > doing this. And it's generally not the best way either (because
> > > it's so hard to do correctly).
You did not quoted me. Anyway, it's fully OK.
> It's no harder to do correctly than to write 'basic' exception-safe
> code.
I do not agree
1) First, in order to write async cancel-safe code (why not to use the
master mode of engine? :-), you will need to constantly set
cancelation state to disabled and back to enabled. Not talking about
standard libraries that are not async-safe and can't be async-safe
having current interfaces. Now let's leave async issue and continue
to talk about deferred cancelation.
2) C++ destructors and cleanup handlers mechanism may be not
integrated by a compiler;
3) cleanup handlers registering may be easily missed by programmer
(while C++ destructor obviously can't). Well, Java try block may be
missed as far;
> Oh, BTW, you can't really do it AT ALL in Java. Java's exceptions
> model is BUSTED, 'interruption' including [almost everything is busted
> in Java - memory mode, 'monitors', etc.]
To begin with - Java has garbage collector so even if programmer does
not make full rollback or even does not preserve invariants, the
resoures (or, probably, more correct - some of them) will not leak.
Monitors will not be blocked after exception is thrown etc. This
examples are not about correct programming but they still demonstrate
that writing java exception safe code is easier then cancel-safe code.
Now, c++ have some paradigms that do not present in java. And they are
danger for exception safe programming. It is bad practice to use
multiple inheritance. It is bad practice to aggregate by value. Let me
hope that in java you can easily swap two class instances in
exception-safe way, while it may be completely impossible in
commonly-acceptable class implementations of C++.
> > I agree. Cancelation is too special to be used for "abandone"
> > notifications. It eventually finishes a thread (while we may want to
> > abandone just a part of calculations) and it asks for too
> > sophisticated coding.
>
> Uhmm. Interesting. Could you please elaborate [lack of standard
> catch-'ability' w.r.t. thread-cancel exceptions aside, please].
Sorry, I did not catch exactly, what you are asking about (besides,
"w.r.t" - what does it mean?)
Anyway, I hope that I clarified my point of view.
Async cancel-safe code must be full of "cancel enable-disable" like
low level code that constantly enables and disables interrupts.
If you have good practice of exception safe coding - you may easily
pass to cancel-safe coding (apart problems #2 and #3). But if you
don't have such a practice - you will probably find that you must pay
too much in order to just cancel a thread. Suppose, even with your
practice, you have old-style CORRECT code written by somebody else -
now go make it cancelable.
Regards,
Michael
PS: are you sure that exception-safe programming is safe and simple
even for you (not to talk about average programmer of 2002)?
Note http://www.research.att.com/~bs/3rd_safe.pdf which is a appendix
BS wrote for his _special_ edition (actually, edition #3.2 ) where he
finally :-)))) (a couple :-) of years after exceptions were introduced
in C++) "demonstrate[s] effective techniques for crafting exception
safe and efficient containers" and "present[s] a few general rules for
exception-safe programming". 3-rd special edition. Better late then
never.
Arnold Hendriks
> multiple inheritance. It is bad practice to aggregate by value. Let me
> hope that in java you can easily swap two class instances in
> exception-safe way, while it may be completely impossible in
> commonly-acceptable class implementations of C++.
work with references to classes. In C++, you can use pointers to classes
and will get exactly the same exception safety with std::swap<Class*,Class*>.
> PS: are you sure that exception-safe programming is safe and simple
> even for you (not to talk about average programmer of 2002)?
It is partly a habits thing. If you learned std::vector, std::string etc
right from the start (eg, read Accelerated C++), basic exception safety
comes for free. If you instead migrated from C to C++, and mostly just
migrated from malloc/free to new/delete, exception-safety is costly.
OTOH, strong exception safety requires much more conscious work, but that's
not relevant if you just want to cleanly abort code.
Alexander Terekhov
Arnold Hendriks wrote:
>
> Michael Podolsky <mich...@identify.com> wrote:
> > multiple inheritance. It is bad practice to aggregate by value. Let me
> > hope that in java you can easily swap two class instances in
> > exception-safe way, while it may be completely impossible in
> > commonly-acceptable class implementations of C++.
> Sorry to bump in, but that's comparing apples with oranges. In Java, you
> work with references to classes. In C++, you can use pointers to classes
> and will get exactly the same exception safety with std::swap<Class*,Class*>.
Wrong!
A) I personally almost always write throw() [throw-nothing] swaps;
B) The C++ standard says [for example]:
"....
no swap() function throws an exception unless that exception
is thrown by the copy constructor or assignment operator of
the container's Compare object (if any; see 23.1.2).
...."
You can't really do it in Java -- due to its brain-dead exception
model [lack of RUNTIME C++-ExSpecs-like enforcement and the presence
of async. exceptions that could pop up EVERYWHERE; others brain-dead
details aside for a moment].
> > PS: are you sure that exception-safe programming is safe and simple
> > even for you (not to talk about average programmer of 2002)?
> It is partly a habits thing. If you learned std::vector, std::string etc
> right from the start (eg, read Accelerated C++), basic exception safety
> comes for free. If you instead migrated from C to C++, and mostly just
> migrated from malloc/free to new/delete, exception-safety is costly.
No. Again, the same principles [transactional approach] apply even WITHOUT
throw-expressions. Exceptions [throws] are just sort-of optimization [you
just canNOT erroneously ignore failures; you don't need to check/bother with
non-exceptional 'operation status' checking; etc.] -- it's simply more 'natural'
way of writing robust programs; benefits w.r.t. diagnostics/debugging under
'correctly'/non-brain-dead done impls -- issues with regards to unneeded
unwinding (no loss of context for debugging/dump-analysis to begin with)
including.
regards,
alexander.
Arnold Hendriks
> Arnold Hendriks wrote:
>> Michael Podolsky <mich...@identify.com> wrote:
>> > multiple inheritance. It is bad practice to aggregate by value. Let me
>> > hope that in java you can easily swap two class instances in
>> > exception-safe way, while it may be completely impossible in
>> > commonly-acceptable class implementations of C++.
>> Sorry to bump in, but that's comparing apples with oranges. In Java, you
>> work with references to classes. In C++, you can use pointers to classes
>> and will get exactly the same exception safety with std::swap<Class*,Class*>.
> Wrong!
What is wrong? In java, you can swap two class references without risking
an exception. In C++, you can swap two class pointers without risking
an exception. So, when you compare swapping class references (apples) to
C++ swapping class pointers (apples) instead of swapping values (oranges),
you get the same exception safety in Java as in C++.
Unless of course, you run out of stack space, since most trivial swap
implementations use the stack for temporary storage.
Alexander Terekhov
Arnold Hendriks wrote:
[...]
>
> Alexander Terekhov <tere...@web.de> wrote:
> > Arnold Hendriks wrote:
> >> Michael Podolsky <mich...@identify.com> wrote:
> >> > multiple inheritance. It is bad practice to aggregate by value. Let me
> >> > hope that in java you can easily swap two class instances in
> >> > exception-safe way, while it may be completely impossible in
> >> > commonly-acceptable class implementations of C++.
>
> >> Sorry to bump in, but that's comparing apples with oranges. In Java, you
> >> work with references to classes. In C++, you can use pointers to classes
> >> and will get exactly the same exception safety with std::swap<Class*,Class*>.
>
> > Wrong!
> What is wrong? In java, you can swap two class references without risking
> an exception.
*THAT* is wrong.
regards,
alexander.
Eric D Crahen
> You can't really do it in Java -- due to its brain-dead exception
> model [lack of RUNTIME C++-ExSpecs-like enforcement and the presence
> of async. exceptions that could pop up EVERYWHERE; others brain-dead
> details aside for a moment].
First of all, complaining about the exception model because runtime
exceptions aren't checked is a completely invalid argument. Checked
exceptions are enforced, a runtime exception by definition is not
enforced.
void swap(Object o1, Object o2) {
Object tmp = o1;
o1 = o2;
o2 = tmp;
}
This isn't going to throw an exception, it doesn't matter that there
is not a no throw clause. In C++ there is an opportunity to override the
assignment operations and have any arbirtray code execute as a result of
the assignment. In Java, there is not.
Secondly, asynchronous exceptions do not occur anywhere. There are only
two situations that an asych exception can occur. One is trying stop()
Threads or ThreadGroups - which is a bad practice to begin with (and
stop() is now deprecated anyway and has been for some time). The other
situation is when there is an error in the VM. This is generally only
going to happen when there is an error beyond your control in the
implementation of the VM or if something goes wrong with the
machine. It only happens as a direct result of your program when you
overflow the stack as the result of going into an infinite recursion
or if you run out of memory (by allocation tons of objects and keeping
references to all of them).
When and where that kind of exception might occur is predictable, when its
a result of a programs actions (and not a hardware failure), and it is
possible to write code the is robust enough to handle these exceptions and
recover from them.
The exception mechanism is functionally very different from async
cancellation and there is no comparision to be made. There is an extensive
description of why runtime exception are included in the Java language and
there are number of texts available that describe how to use this
effectively. Its a tool and like anything else, if you use it incorrectly
(for things its not designed for) you will have problems and it would be
your fault. If I take a chainsaw to my leg, I'm left with a big
problem, does that make a chainsaw brain-dead? No it doesn't, that's my
fault - not the chainsaws.
- Eric
http://www.cse.buffalo.edu/~crahen
Alexander Terekhov
Eric D Crahen wrote:
>
> On Thu, 13 Jun 2002, Alexander Terekhov wrote:
>
> > You can't really do it in Java -- due to its brain-dead exception
> > model [lack of RUNTIME C++-ExSpecs-like enforcement and the presence
> > of async. exceptions that could pop up EVERYWHERE; others brain-dead
> > details aside for a moment].
>
> First of all, complaining about the exception model because runtime
> exceptions aren't checked is a completely invalid argument.
That's NOT my argument (read again the referenced articles on ExSpecs).
> Checked exceptions are enforced, a runtime exception by definition
> is not enforced.
What do you mean? Nothing is 'enforced' AT RUNTIME in Java's exception
model.
> void swap(Object o1, Object o2) {
>
> Object tmp = o1;
>
> o1 = o2;
> o2 = tmp;
>
> }
>
> This isn't going to throw an exception, it doesn't matter that there
> is not a no throw clause.
No, it DOES matter. Without it, the implicit clause is
'throws RuntimeException, Error" -- that's is NOT equal
to C++'s 'throw()' (nothrow ENFORCED guarantee). Heck,
what else do you want as a proof that Java's exception
model is totally BRAIN-DEAD.
[...]
> Secondly, asynchronous exceptions do not occur anywhere. There are only
> two situations that an asych exception can occur. One is trying stop()
> Threads or ThreadGroups - which is a bad practice to begin with (and
> stop() is now deprecated anyway and has been for some time).
Correct.
> The other
> situation is when there is an error in the VM. This is generally only
> going to happen when there is an error beyond your control in the
> implementation of the VM or if something goes wrong with the
> machine. It only happens as a direct result of your program when you
> overflow the stack as the result of going into an infinite recursion
> or if you run out of memory (by allocation tons of objects and keeping
> references to all of them).
So what? What if it DOES happen? Silly Java VM is going to unwind the
whole mess... 'synchronized' scopes including... exposing broken
invariants to INNOCENT threads; anything could happen then; the entire
universe could then COLLAPSE due to some broken program logic resulting
from such exposure of totally silly/broken stuff.
> When and where that kind of exception might occur is predictable, when its
> a result of a programs actions (and not a hardware failure), and it is
> possible to write code the is robust enough to handle these exceptions and
> recover from them.
Yeah, dream on.
regards,
alexander.
Michael Podolsky
> Michael Podolsky wrote:
> > multiple inheritance. It is bad practice to aggregate by value. Let me
> > hope that in java you can easily swap two class instances in
> > exception-safe way, while it may be completely impossible in
> > commonly-acceptable class implementations of C++.
> Sorry to bump in, but that's comparing apples with oranges. In Java, you
> work with references to classes. In C++, you can use pointers to classes
> and will get exactly the same exception safety with std::swap<Class*,Class*>.
Let me clarify my statement. I am not going to explain that you can
easily swap (or assign) pointers, while you can't do it in exception
safe maner for objects themselves. That is trivial.
What is less trivial - you can't swap or assign the values of objects
instances unless that object instances does not use multiple
inheritance and does not aggregate other object instances by value.
The last one (designing objects that directly (by value) aggregate
other objects is common practice in C++, while it is simply
unimplementable in Java.
When I talk about a swap - I mean not trivial swapping poitners to
objects (or references to objects in Java), but swapping (or
exception-safe reassigning with the help of unthrowing swap) the
VALUES of objects. This exception-safe VALUE reassignment or VALUE
swap is trivial in Java and generally unimplementable in C++.
Eric D Crahen
> That's NOT my argument (read again the referenced articles on ExSpecs).
>
> > Checked exceptions are enforced, a runtime exception by definition
> > is not enforced.
>
> What do you mean? Nothing is 'enforced' AT RUNTIME in Java's exception
> model.
Your argument is that there is a lack of runtime enforcement so its
broken.
- A runtime exception by definition is not checked
- JLS # 11.2.2 explains why it is not checked.
- Most good book about the java language will teach you how to
use runtime exceptions effectively.
All you've said is that you consider the exception model broken. Do you
have any code that demonstrates a problem?
> > void swap(Object o1, Object o2) {
> >
> > Object tmp = o1;
> >
> > o1 = o2;
> > o2 = tmp;
> >
> > }
> >
> > This isn't going to throw an exception, it doesn't matter that there
> > is not a no throw clause.
> No, it DOES matter. Without it, the implicit clause is
> 'throws RuntimeException, Error" -- that's is NOT equal
> to C++'s 'throw()' (nothrow ENFORCED guarantee). Heck,
> what else do you want as a proof that Java's exception
> model is totally BRAIN-DEAD.
I don't think so. That will absolutely not throw a runtime exception.
Nothing about it implies that a runtime exception could be thrown.
Java doesn't need checked runtime exceptions, it doesn't face the same
challanges C++ does when it comes to using them correctly. For example,
there are no destrutors that can throw as the stack unwinds; there are
no overloaded operators that you might want to declare as nothrow.
The languages are just different, there isn't much to compare past the
basic structure of things.
> > The other
> > situation is when there is an error in the VM. This is generally only
> > going to happen when there is an error beyond your control in the
> > implementation of the VM or if something goes wrong with the
> > machine. It only happens as a direct result of your program when you
> > overflow the stack as the result of going into an infinite recursion
> > or if you run out of memory (by allocation tons of objects and keeping
> > references to all of them).
>
> So what? What if it DOES happen?
You missing the point. You describe this as though ever Java program
is in constant peril because maybe an InternalError will occur. This is
just not the case. Its very predicable when and where it can occur, you
are given the tools to handle that error, the language is designed so
that this is possible.
There are a number of massive enterprise applications that are Java based
and are in use everyday. Why aren't they crashing left and right if
this is such a danger?
> Silly Java VM is going to unwind the
> whole mess... 'synchronized' scopes including... exposing broken
> invariants to INNOCENT threads; anything could happen then; the entire
> universe could then COLLAPSE due to some broken program logic resulting
> from such exposure of totally silly/broken stuff.
If you chose to ignore the exception, yes. But its an exception you can
catch it and you handle it. You can structure your code so that the
handler still happens inside the apporopriate synchronized blocks
and you can maintain a consistent state. If you ignore an exception, your
asking for trouble.
Are you suggesting unwinding the stack is not the appropriate action?
At least that way you are given a chance to deal with the error in a
way that makes sense. The alternative being to just remove the thread, or
to transfer control to someplace that does not unwind the stack is only
more dangerous.
> > When and where that kind of exception might occur is predictable, when its
> > a result of a programs actions (and not a hardware failure), and it is
> > possible to write code the is robust enough to handle these exceptions and
> > recover from them.
>
> Yeah, dream on.
Give me an example of real code that you can't deal with because of
a runtime exception and I will show you how to fix it.
- Eric
http://www.cse.buffalo.edu/~crahen
Alexander Terekhov
Eric D Crahen wrote:
>
> On Thu, 13 Jun 2002, Alexander Terekhov wrote:
>
> > That's NOT my argument (read again the referenced articles on ExSpecs).
> >
> > > Checked exceptions are enforced, a runtime exception by definition
> > > is not enforced.
> >
> > What do you mean? Nothing is 'enforced' AT RUNTIME in Java's exception
> > model.
>
> Your argument is that there is a lack of runtime enforcement so its
> broken.
Correct. That's just one argument.
> - A runtime exception by definition is not checked
Heck, 'checked' != *runtime enforcement*/'fencing'.
> - JLS # 11.2.2 explains why it is not checked.
> - Most good book about the java language will teach you how to
> use runtime exceptions effectively.
>
> All you've said is that you consider the exception model broken. Do you
> have any code that demonstrates a problem?
>
> > > void swap(Object o1, Object o2) {
> > >
> > > Object tmp = o1;
> > >
> > > o1 = o2;
> > > o2 = tmp;
> > >
> > > }
> > >
> > > This isn't going to throw an exception, it doesn't matter that there
> > > is not a no throw clause.
>
> > No, it DOES matter. Without it, the implicit clause is
> > 'throws RuntimeException, Error" -- that's is NOT equal
> > to C++'s 'throw()' (nothrow ENFORCED guarantee). Heck,
> > what else do you want as a proof that Java's exception
> > model is totally BRAIN-DEAD.
>
> I don't think so. That will absolutely not throw a runtime exception.
> Nothing about it implies that a runtime exception could be thrown.
But it could.
> Java doesn't need checked runtime exceptions, it doesn't face the same
> challanges C++ does when it comes to using them correctly.
That's just a rather widely popular misconception. C++ ExSpecs are
FENCES; they are NOT supposed to 'enforce' you to write silly catch
clauses no matter whether it makes sense or not.
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
http://groups.google.com/groups?selm=c29b5e33.0202110310.413c19cb%40posting.google.com
> For example,
> there are no destrutors that can throw as the stack unwinds;
But anything inside any 'finally' CAN THROW AS THE STACK UNWINDS.
Oh, BTW: http://groups.google.com/groups?selm=3CC1ABD8.971E71BF%40web.de
[...]
> Are you suggesting unwinding the stack is not the appropriate action?
Yes, unwinding on any UNEXPECTED exception is indeed "not the
appropriate action" -- totally brain-dead thing [that's just
like to pretend that one could/should unwind on asserts, SIGSEGV,
etc.].
> At least that way you are given a chance to deal with the error in a
> way that makes sense.
C++-like terminate()-handlers invoked at throw point is the best that
you can do [for emergency interprocess cleanup -- things like turning
off the speaker, etc.].
[...]
> Give me an example of real code that you can't deal with because of
> a runtime exception and I will show you how to fix it.
No, give ME please an example of NOTHROW code in Java, to begin with.
regards,
alexander.
Eric D Crahen
> But it could.
You are wrong. Show realistic code that causes that swap() function
to throw unexpectedly w/o using deprecated methods. Prove that it
could.
> But anything inside any 'finally' CAN THROW AS THE STACK UNWINDS.
Only if you write code that throws an exception in the finally clause.
It's within your power to write a finally clause that will not, and its
easy to accomplish in Java.
> > At least that way you are given a chance to deal with the error in a
> > way that makes sense.
>
> C++-like terminate()-handlers invoked at throw point is the best that
> you can do [for emergency interprocess cleanup -- things like turning
> off the speaker, etc.].
No more safe than allowing the stack to unwind. A terminate handler is
forcing you to quit, and you aren't going to get the chance to do it
elegantly; you've given up on the hope for a clean exit by even reaching
this point.
However, in Java, almost all runtime exceptions can easily be
recovered from, and where and when they occur are documented. There
really aren't any unexpected exceptions, all of them are predicatble,
with the exception of VirtualMachineErrors. Some of those are within
your control as well. The StackOverflowError you can prevent from occuring
and the OutOfMemoryError you can recover from depending on how you write
your code (and you can avoid the OutOfMemoryError to begin with). T
If you want to don't want to unwind the stack and want to exit you can
call System.exit() whenever you want; which can be used to simulate a
termination handler. You could even make this more automatic if you wanted
to by using the Proxy class, though there would be little to gain.
Allowing the stack to unwind does not prevent you from doing this; and if
you achieve the desired behavior you really have no reason to call this
flawed. Expecting Java to be C or C++ is an error on your part to begin with.
> > Give me an example of real code that you can't deal with because of
> > a runtime exception and I will show you how to fix it.
>
> No, give ME please an example of NOTHROW code in Java, to begin with.
No need; unless you can demonstrate an actual problem with _real code_
that would require this there no point. You refuse because you can't do it.
If you can prove me wrong, please do so.
- Eric
http://www.cse.buffalo.edu/~crahen
Michael Podolsky
> Eric D Crahen wrote:
> > void swap(Object o1, Object o2) {
> >
> > Object tmp = o1;
> >
> > o1 = o2;
> > o2 = tmp;
> >
> > }
> >
> > This isn't going to throw an exception, it doesn't matter that there
> > is not a no throw clause.
>
> No, it DOES matter. Without it, the implicit clause is
> 'throws RuntimeException, Error" -- that's is NOT equal
> to C++'s 'throw()' (nothrow ENFORCED guarantee). Heck,
> what else do you want as a proof that Java's exception
> model is totally BRAIN-DEAD.
Whaaat?
This so called "swap" function is usable for nothing as it does not
affect the arguments of the caller.
BTW, because of this fact, it is completely exception safe. :-)))
Regards,
Michael
Michael Podolsky
> > Arnold Hendriks wrote:
> >> Michael Podolsky <mich...@identify.com> wrote:
> >> > multiple inheritance. It is bad practice to aggregate by value. Let me
> >> > hope that in java you can easily swap two class instances in
> >> > exception-safe way, while it may be completely impossible in
> >> > commonly-acceptable class implementations of C++.
>
> >> Sorry to bump in, but that's comparing apples with oranges. In Java, you
> >> work with references to classes. In C++, you can use pointers to classes
> >> and will get exactly the same exception safety with std::swap<Class*,Class*>.
>
> > Wrong!
> What is wrong? In java, you can swap two class references without risking
> an exception. In C++, you can swap two class pointers without risking
> an exception. So, when you compare swapping class references (apples) to
> C++ swapping class pointers (apples) instead of swapping values (oranges),
> you get the same exception safety in Java as in C++.
Let me clarify my statement. I am not going to explain that you can
easily swap (or assign) pointers, while you can't do it in exception
safe maner for objects themselves. That is trivial.
What is less trivial - you can't swap or assign the values of objects
instances unless that object instances does not use multiple
inheritance and does not aggregate other object instances by value.
The last one (designing objects that directly (by value) aggregate
other objects is common practice in C++, while it is simply
unimplementable in Java.
When I talk about a swap - I mean not trivial swapping poitners to
objects (or references to objects in Java), but swapping (or
exception-safe reassigning with the help of unthrowing swap) the
VALUES of objects. This exception-safe VALUE reassignment or VALUE
swap is trivial in Java and generally unimplementable in C++.
Regards,
Michael
Michael Podolsky
> you can't swap or assign the values of objects
> instances unless that object instances does not use multiple
> inheritance and does not aggregate other object instances by value.
Well, after looking a while, I have found many (many,many) "bugs" in
my previous statement. So don't take it as completely correct rule,
while it still (even being not particularly correct) demonstrates my
point: you can easily get C++ class where assignment or swap operation
can't be implemented in exception-safe manner, while in java you can
easily "assign" or swap INSTANCES (not references), providing
exception-safe guarnatee.
Regards,
Michael
Alexander Terekhov
Eric D Crahen wrote:
>
> On Thu, 13 Jun 2002, Alexander Terekhov wrote:
>
> > But it could.
>
> You are wrong. Show realistic code that causes that swap() function
> to throw unexpectedly w/o using deprecated methods. Prove that it
> could.
Okay, here is the proof, Eric:
< from java.sun.com site >
---
Copyright © 1999 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections through our feedback
form
---
---
Copyright © 2000 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections to j...@java.sun.com
---
11.5.2 Virtual Machine Errors
The Java virtual machine throws an object that is an instance of
a subclass of the class VirtualMachineError when an internal error
or resource limitation prevents it from implementing the semantics
of the Java programming language. See The Java Virtual Machine
Specification Second Edition for the definitive discussion of
these errors.
6.3 Virtual Machine Errors
A Java virtual machine implementation throws an object that is
an instance of a subclass of the class VirtualMachineError when
an internal error or resource limitation prevents it from correctly
implementing the Java programming language. The Java virtual machine
^^^^^^^^^^^^^^^^^^^^^^^^
specification cannot predict where resource limitations or internal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
errors may be encountered and does not mandate precisely when they
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
can be reported. Thus, any of the virtual machine errors listed as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
subclasses of VirtualMachineError in Section 2.16.4 may be thrown
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at any time during the operation of the Java virtual machine.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A Java virtual machine implementation throws an object that is an
instance of a subclass of the class VirtualMachineError when an
internal error or resource limitation prevents it from implementing
the semantics of the Java programming language. This specification
defines the following virtual machine errors:
InternalError: An internal error has occurred in the Java virtual
machine implementation because of a fault in the software implementing
the virtual machine, a fault in the underlying host system software,
or a fault in the hardware. This error is delivered asynchronously
when it is detected and may occur at any point in a program.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OutOfMemoryError: The Java virtual machine implementation has run
out of either virtual or physical memory, and the automatic storage
manager was unable to reclaim enough memory to satisfy an object
creation request.
StackOverflowError: The Java virtual machine implementation has
run out of stack space for a thread, typically because the thread
is doing an unbounded number of recursive invocations as a result
of a fault in the executing program.
UnknownError: An exception or error has occurred, but the Java
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
virtual machine implementation is unable to report the actual
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
exception or error.
^^^^^^^^^^^^^^^^^^
regards,
alexander.
Eric D Crahen
> Please let me know when you will finally reach the 'stage'
> [AFAIK, it normally/usually occurs to kids of around 10-12
> years old] of understanding the difference between "concrete
> code that demonstrates a real problem" on one hand and
> PROGRAMMING MODELS WHICH DEFINE ENVIRONMENT/RULES under
> which people write "concrete code", on the other hand.
That's very mature of you. There is no need for name calling. I didn't
realize asking for a programmer to apply his knowledge to demonstrate a
problem would cause such a reaction. You've had no problem posting code
that demonstrates problems and solutions in the past.
> Hard drives aren't defined in Java's exception model.
Wrong. The InternalError are UnknownError exceptions are used to report
VM bugs & hardware errors on the platform underlying the VM. All the
exception model says is this how an error will be reported - there is
no limitation on what kinds of errors may be reported.
> Implicit "throws RuntimeException, Error" IS DEFINED
> IN THE JAVA'S EXCEPTION MODEL.
This is not a problem. And what are you arguing now? First was
asychronous exceptions can occur anytime so you thought that might be a
problem. Those async exceptions are rare and reservered for show stopping
errors. So, now its that synchronous runtime exceptions exist and are a
problem? If so, please demonstrate. Illustrate the problem with code.
> You are wrong. I am right. The model is BRAIN-DEAD.
You should either stop using this offsensive term at every opportunity;
or on the other hand maybe you should just go all with it and start
mixing in racial slurs as well. Just say flawed or broken.
> It's IMPOSSIBLE to write *exception-safe* code in Java.
You contradict yourself. First you say that a programming model and
concrete code are different animals (and imply not neccessarily connected,
which is why you seem to not want to demonstrate anything with code). Here
you are saying that concrete code that is exception safe is not possible
to write because the programming model is flawed in some way (which
implies that they are connected and it is indeed possible to write code
that reflects the model accurately). So if its not possible to write
exception safe code in Java, then it must at least be possible to write
code than can not be made exception safe right? So show us.
You are the one making claims about a problem in the model of language
that you claim affect real code written in practice. I'm only asking you
to backup your claim with code that can demonstrate it. This is not the
outrageous request you are making it out to be.
Alexander Terekhov
Eric, you forgot to include the private message to which
I was replying in the quoted text below. Here it is:
"Eric D Crahen <cra...@cse.Buffalo.EDU> schrieb am 14.06.02 17:41:53:
> The OutOfMemory error and StackOverflowError are thrown synchronously
> in most current VM implementations, even though the spec says otherwise.
> Not mention that you can completely avoid both of these to begin with.
>
> And if there is another VM exception, there is a serious problem with
> the system. Either the implementation has a bug or the system has a
> problem and both are beyond your control. If someone comes along and yanks
> a hard drive while your program is running it doesn't matter what the
> exception model is, your program is done.
>
> So, I'll ask again. Show code that proves that asynchrouns exception
> in Java are a serious problem that plague every piece of code as your
> claimed earlier.
>
> Quote all you want, it doesn mean a thing. What matters is what you can do
> in reality and so far you have shown us you can do nothing other than quote
> texts. Anybody can look something up an highlight it, thats nothing
> special. Until yousome concrete code that demonstrates a real problem, you
> have no bite to back up your bark.
Please let me know when you will finally reach the 'stage'
...."
Eric D Crahen wrote:
>
> On Fri, 14 Jun 2002, Alexander Terekhov wrote:
>
> > Please let me know when you will finally reach the 'stage'
> > [AFAIK, it normally/usually occurs to kids of around 10-12
> > years old] of understanding the difference between "concrete
> > code that demonstrates a real problem" on one hand and
> > PROGRAMMING MODELS WHICH DEFINE ENVIRONMENT/RULES under
> > which people write "concrete code", on the other hand.
>
> That's very mature of you. There is no need for name calling. I didn't
> realize asking for a programmer to apply his knowledge to demonstrate a
> problem would cause such a reaction. You've had no problem posting code
> that demonstrates problems and solutions in the past.
Heck, what code do you want from me? I'm talking about
brain-dead things in Java's exception model >>MODEL<<:
http://groups.google.com/groups?selm=3C73AB86.99B8CBE0%40web.de
http://groups.google.com/groups?selm=d6651fb6.0202220353.6dced986%40posting.google.com
http://groups.google.com/groups?selm=3C76A95C.DEB241D7%40web.de
< from the 2nd link above >
"....
> My humbly judgment w.r.t the whole Java exception model is that this
> damn thing is "broken to the point of being unusable" for any
> serious (other than "toy"/ "applet") programming. Here are just a
> few reasons:
> a) lack of "throw()" and RUNTIME enforcement
> in general;
I agree. On the other hand, can you write a function which cannot
throw InternalError (which is raised in case of an internal error in
the VM)?
> b) the presence of async.exceptions *without*
> having a clean concept of something along
> the lines of Pthread's "Async Cancel Safety";
> c) NO way to automatically abort/dump/invoke
> debugger AT THROW POINT (before that useless
> and harming unwinding) in the case of uncaught
> (unexpected) throws;
> d) colliding throw (from finally clause) just
> "replace" the first/previous one!
> C++ exception model, while perhaps missing a few useful extras[1],
> is MUCH better and MORE reasonable thing, I think.
I would agree. There are actually a couple of places where I would
have said that it was hard to do worse than C++, but Java succeeded.
...."
< from the 3rd link above >
"....
> It's actually throws RuntimeException, Error.
>
> And while you can add to the list, you cannot override it.
Yup.
[...]
> > a) lack of "throw()" and RUNTIME enforcement
> > in general;
>
> I agree. On the other hand, can you write a function which cannot
> throw InternalError (which is raised in case of an internal error in
> the VM)?
Java VM? If so, that is exactly "b)" point on the 2nd line below! ;-)
> > b) the presence of async.exceptions *without*
> > having a clean concept of something along
> > the lines of Pthread's "Async Cancel Safety";
"Asynchronous exceptions are rare. They occur only as a result of:
<...deprecated stop...>
An internal error (§11.5.2) in the Java virtual machine"
Personally, I think that asynchronous thread cancellation
(i.e. exception) IS rather handy thing and language support
(to ensure/enforce safety of async-cancel-safe regions) would
make it even more USEFUL.
...."
> > Hard drives aren't defined in Java's exception model.
>
> Wrong. The InternalError are UnknownError exceptions are used to report
> VM bugs & hardware errors on the platform underlying the VM. All the
> exception model says is this how an error will be reported - there is
> no limitation on what kinds of errors may be reported.
>
> > Implicit "throws RuntimeException, Error" IS DEFINED
> > IN THE JAVA'S EXCEPTION MODEL.
>
> This is not a problem. And what are you arguing now?
See a) and b) and c) and d) above; since Feb. I simply had
not enough time to expand the list, thus far. ;-) ;-) ;-)
regards,
alexander.
Alexander Terekhov
Eric D Crahen wrote:
[...]
> You are the one making claims about a problem in the model of language
> that you claim affect real code written in practice. I'm only asking you
> to backup your claim with code that can demonstrate it. This is not the
> outrageous request you are making it out to be.
Okay, here is the {pseudo}code (BTW, this entire 'boost' thread is quite
interesting too ;-) ):
http://lists.boost.org/MailArchives/boost/msg22981.php
(Re: first sight)
"....
Also, with respect to auto_rethrow_exception:
scoped_lock lock( systemWideMutex );
beginUpdates(); // modify something; nothrow
try
{
// ... plug-in oper ;-) strong
}
// ...
catch(...)
{
// ...
}
finalizeUpdates(); // final modifications; nothrow
...."
Now, imagine that finalizeUpdates() calls a couple of should-be-nothrow
swaps and one of them suddenly throws -- in full compliance with Java's
exceptions model...
regards,
alexander.
P.S. http://lists.boost.org/MailArchives/boost/msg23046.php
"....
> try
> {
> // ... plug-in oper ;-) strong
> }
> // ... nothrow
> catch(...)
> {
> // ... nothrow
> }
>
> cout << When do we reach this point? << endl;
Sorry, you've already convinced me. I didn't think hard enough
about
your last post.
Bill Kempf"
Eric D Crahen
> I agree. On the other hand, can you write a function which cannot
> throw InternalError (which is raised in case of an internal error in
> the VM)?
Not neccessary.
The important thing you are overlooking is that if there is an
InternalError, its because of a problem in the VM. It doesn't happen as
a random occurance, its the result of a specific problem in the virtual
machine implementation or the in the system your running on. Its
not something that just happens from time to time. On a stable machine on
a stable VM with bytecode that is correctly formed this is not an
exception you will see.
> Java VM? If so, that is exactly "b)" point on the 2nd line below! ;-)
>
> > > b) the presence of async.exceptions *without*
> > > having a clean concept of something along
> > > the lines of Pthread's "Async Cancel Safety";
>
> "Asynchronous exceptions are rare. They occur only as a result of:
> <...deprecated stop...>
> An internal error (§11.5.2) in the Java virtual machine"
>
> Personally, I think that asynchronous thread cancellation
> (i.e. exception) IS rather handy thing and language support
> (to ensure/enforce safety of async-cancel-safe regions) would
> make it even more USEFUL.
> ...."
Maybe, but its often easier to design so it is not required.
- Eric
http://www.cse.buffalo.edu/~crahen
Eric D Crahen
> Okay, here is the {pseudo}code (BTW, this entire 'boost' thread is quite
> interesting too ;-) ):
>
> scoped_lock lock( systemWideMutex );
>
> beginUpdates(); // modify something; nothrow
>
> try
> {
> // ... plug-in oper ;-) strong
> }
> // ...
> catch(...)
> {
> // ...
> }
>
> finalizeUpdates(); // final modifications; nothrow
> ...."
>
> Now, imagine that finalizeUpdates() calls a couple of should-be-nothrow
> swaps and one of them suddenly throws -- in full compliance with Java's
> exceptions model...
Well for one thing an assignment will not throw. Refrain from using
deprecated methods that are explicity described as unsafe and you will not
be using code that susceptible to async exceptions.
You can write a finalizeUpdates() method that does more complicated
things and does not throw. You know what exceptions the code you want to
execute can throw, so you can write a method that catches them and
handles them appropriately.. Its not difficult to do this.
Having a no throw clause isn't helping you deal with an error
any better. The error occurred for a reason, ignoring it certainly
doesn't help make a program any more stable.
Alexander Terekhov
Eric,
On a stable machine on a stable VM during the season when all
exceptions are totally busy making kids [future generations],
you are completely right -- nothing bad will happen. The rest
of the calendar year is a somewhat different thing, however.
regards,
alexander.
Eric D Crahen
> On a stable machine on a stable VM during the season when all
> exceptions are totally busy making kids [future generations],
> you are completely right -- nothing bad will happen. The rest
> of the calendar year is a somewhat different thing, however.
Run your code in VM like Sun's most recent one, don't use deprecated
methods and don't do something like manually write your own bytecode hand
and you will find yourself in and environment that is not going
to be throwing async exceptions; nothing bad will happen (all year round).
Chris Smith
> methods and don't do something like manually write your own bytecode hand
> and you will find yourself in and environment that is not going
> to be throwing async exceptions; nothing bad will happen (all year round).
http://developer.java.sun.com/developer/bugParade/bugs/4615343.html
http://developer.java.sun.com/developer/bugParade/bugs/4466993.html
http://developer.java.sun.com/developer/bugParade/bugs/4517321.html
These (and more... I just grabbed a few from Bug Parade) are all ways to
get entirely unexpected exceptions on the most recent implementations of
Java. Are they truly "asynchronous"? Perhaps not... but they do happen
without any warning, and the prevalence of such situations suggest that
there are probably others as well. Since they aren't documented and
can't be reliably predicted, you have to treat them as essentially
asynchronous exceptions.
Chris Smith
Eric D Crahen
> These (and more... I just grabbed a few from Bug Parade) are all ways to
> get entirely unexpected exceptions on the most recent implementations of
> Java. Are they truly "asynchronous"? Perhaps not...
None of them are asynchronous which makes it much easier to handle and
recover from. I was talking about an error in the implementation of the VM
itself that would cause asynch errors to be thrown unexpectedly.
> but they do happen without any warning, and the prevalence of such
> situations suggest that there are probably others as well.
> Since they aren't documented and can't be reliably predicted,
> you have to treat them as essentially asynchronous exceptions.
This doesn't make it impossible to write exception safe code. All I
am trying to make clear is that asynch exceptions are not a common a
occurance and can be controlled and that the prescence of runtime
exceptions does not make it impossible to write exception safe code in
Java. Microsofts Visual C++ has had a number of bugs in its STL
implementation over the years, does that make it impossible to write safe
code in C++? Every language has libraries that have bugs in them; that
doesn't make the languages themselves flawed.
Anyway, this has gotten really far off-topic and I really don't
want to argue about this anymore since it won't produce anything
fruitful. It's not my job to be the thought-police, if people want to hate
Java because its not something else, go right ahead :)
- Eric
http://www.cse.buffalo.edu/~crahen
Ed Jensen
: No, it DOES matter. Without it, the implicit clause is
: to C++'s 'throw()' (nothrow ENFORCED guarantee). Heck,
: what else do you want as a proof that Java's exception
: model is totally BRAIN-DEAD.
The latest issue of C/C++ Users Journal has an interesting
article on this very subject. I only skimmed it, but what
I gathered is that C++'s 'throw()' does not, in fact,
guarantee that no exceptions will be thrown. Furthermore,
I got the impression that the C++ committee itself considered
C++'s specification on the matter rather undesirable.
Corrections welcome.
-Ed