[c++-pthreads] Re: [SPAM] - Re: [c++-pthreads] pthread_cancel and EH: let's try this again - Email found in subject
Ted Baker
baker at cs.fsu.edu
Mon Jul 18 21:25:50 UTC 2005
> My analogy was "gotos", for which the safe pattern
> eventually made their way into standard control structures.
>
> In Java, an attempt was made to do something similar for pointers,
> like it or not.
>
> Maybe it is time for a language to look at exceptions along the
> same lines, i.e., to build in structures for exceptions that rule
> out the most frequent forms of erroneous usage.
I forgot another analogy. Several languages, including Concurrent
Pascal and Ada, have built in monitor-like structures that enforce
safe patterns for concurrent programming that can prevent the most
common errors one makes when using low-level synchronization
primitives like POSIX mutexes and condition variables, such as
forgetting to release a lock, trying to seize a lock that one
already holds, trying to sleep on a condition without holding
the lock, waking up without rechecking the logical condition
associated with the sleep, etc.
Apologies for harping on the same chord.
My point is still that (raw) exceptions are not a simple feature
to use correctly, generally tend to get programmers in trouble,
and don't need any "help" that will encourage people to try to
use them for more unsafe things.
The idea of thread cancellation is very simple and very appealing,
so programmers to are told about it will seize on it as a panacea.
I've seen this among students in the courses where I teach
programming with threads (using C).
Such naive programmers will write a program using threads, and
then try to shut a thread or threads down by just cancelling them.
They do not fully understand the ramifications of the thread
cancellation model, use whatever libraries are at hand, and do not
design from the beginning with cancellation in mind. As a result,
they run into trouble, such as lockups due to cancellation or
threads that are holding mutexes on which another thread is
depending for a pthread_cond_signal to wake up.
--Ted
More information about the c++-pthreads
mailing list