Re: To thread or not to thread ?
Le Chaud Lapin wrote:
Lourens Veen wrote:
Why not use C++' exception mechanism to cancel threads? The owner of a
thread object (or handle or reference or whatever) calls a cancel()
function which causes a thread_cancelled exception to be thrown in
that thread. Then cleanup can happen by the normal exception
handlers.
It seems from a quick web search that this idea is obvious enough that
it's been at least tried before. I can see a problem with throw()
declarations becoming somewhat less of a guarantee, and there would
have to be a very careful specification of at which points the
exception would become visible. Perhaps it would even be useful to
have atomic blocks that would execute fully before the exception
became visible if it were thrown halfway. If any kind of jumping or
looping would be disallowed inside an atomic block, the exception
would eventually be thrown.
I haven't thought this through properly, so maybe there's something
obvious I'm missing, but it seems logical.
By doing so, you would implicitly stipulate that exceptions can be
thrown asynchronously, meaning that the thread can be interrupted no
matter what it is doing, at any point in time.
That's not necessarily implementable. Depending on how the
compiler generates function prologues, there could easily be
instances where a stack walkback would be simply impossible.
Lourens may be referring to the text in the rationale section of
Posix specification of pthread_cleanup_push and
pthread_cleanup_pop: "Note that the specified cleanup handling
mechanism is especially tied to the C language and, while the
requirement for a uniform mechanism for expressing cleanup is
language-independent, the mechanism used in other languages may
be quite different. In addition, this mechanism is really only
necessary due to the lack of a real exception mechanism in the C
language, which would be the ideal solution." The last sentence
is particularly interesting in a C++ context (but I know of no
C++ compiler at present which gives you a catchable exception
when a thread is cancelled). Note, however, that cancellation
under Posix is not normally asynchronous; the Posix standard
defines a certain number of cancellation points, and the
cancellation will be deferred until the thread to be cancelled
is at one of these points. (Note that all potentially blocking
requests, like read(), recv(), or pthread_cond_wait()---but not
pthread_mutex_wait()!---are cancellation points. There is also
a request pthread_testcancel() which does nothing except create
a cancellation point.)
Note that with g++, thread cancellation does NOT call the
destructors of local objects in the thread. Which means that
for all practical purposes, it cannot be used.
This would amount to
rogue termination under the guise of the normalcy of protection, and
rogue termination is possible now. Even operator new() with its
ubiquity and potential to throw bad_alloc(), provides mechanism for
predictability and order - it will not cause an exception to be thrown
at "any point in time", say, half-way through modifying a global
structure.
Correct. This is very, very important. You can't allow fully
asynchronous termination and expect to get a working program.
If it is required that a thread cannot be interrupted "at any point in
time", but at a "well known check point", then those points would have
to be interspersed in the code everywhere by the compiler to support
expedient cancellation. If you allow that, one could argue that you
should allow the programmer to use the flag testing technique that John
Q mentioned. But if you allow flag testing, not only do you have to
keep testing "everywhere", setting up the flag to be tested under each
execution scenario, you essentially implement a
execute-real-code-plus-execute-spin-on-semaphore situation, where
checking the flag involves use of CPU cycles to test the flag.
That's not the real problem. The real problem is that you
cannot test the flag when you're blocked, say reading a socket.
The standard solution is to use a time-out on the read, and poll
the flag whenever the time-out expires. (Another solution, at
least under Unix, is to create a pipe and associate it with such
flags; anytime you modify the flag, you then write a byte in the
pipe, and any thread interested in the flag will add the pipe to
its list of devices waited for in the select.)
And then the problem becomes clear:
The requirement of abrupt termination means that the canceled thread
must not wait too long to check its flag. But if it is not to wait to
long, that means it must spend much time checking the flag, which is
extremely wasteful, especially in times when it has nothing else to do.
It's even more wasteful when the thread has real work to do.
Still, in practice, if we're talking about clean shut-down,
checking the flag once a second is typically sufficient, and it
shouldn't take more than a couple of microseconds to check. So
it shouldn't be a serious problem unless we have a couple of
thousand threads checking.
More importantly in the nothing-else-to-do-but-check-flag situation,
you would have to determine the "optimal" "inter-wait duration" for
checking the "time-to-die" flag. You will wonder if 1 second is
enough. You will wonder if 5 seconds is enough. You will see that in
certain cases, 100 milliseconds is absolutely positively too much. And
you will have to have this conversation with yourself each and every
time you use this method.
With events, there is no waste in time, and there is no ambiguity about
"when to check". The thread to be canceled can block indefinitely and
know that it will not have to worry about dying promptly at the behest
of another thread, because triggering of the event by the external
thread will result in immediate unblocking. You simply right your code
(pun intended), and let the kernel-mode machinery do what it is best
at.
How does this solve the problem of having to check when you're
doing intensive CPU? You still have to poll from time to time.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]