Re: Boost.Threads - 'lock' name (was Re: Boost.Thread

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-20 05:54:05

> > note that this concept alone is somewhat
> > less robust/helpful than POSIX cancellation
> > cleanup handlers; releasing the lock with
> > associated data left in broken state is not
> > really helpful.. btw, that is why win32
> > ABANDONED mutex state is practically
> > useless and is rather brain damaged
> > concept, IMHO.
>
> You can't compare these two.  An abandoned mutex is in a very
> different state then the mutex that's been automatically released.
> In fact, there is exactly ZERO difference between the program stack
> cleaning up resources and your POSIX clean up stack cleaning up
> resources.  Your argument about data being left in a "broken state"
> applies equally to both, and are handled by user code in either a
> clean up handler or destructor/catch block.  It's just as easy to do
> this wrong with both styles.

Bill, i was not talking about "how it works"; i was trying to
highlight *what* posix cancellation cleanup handler is supposed
to do in the most usual case - handling of cancellation-wait points.
consider the following example from the standard:

32408 void
32409 waiting_writer_cleanup(void *arg)
32410 {
32411 rwlock *l;
32412 l = (rwlock *) arg;
32413 if ((--l->waiting_writers == 0) && (l->lock_count >= 0)) {
32414 /*
32415 * This only happens if we have been canceled.
32416 */
32417 pthread_cond_broadcast(&l->wcond);
32418 }
32419 pthread_mutex_unlock(&l->lock);
32420 }
32421 void
32422 lock_for_write(rwlock *l)
32423 {
32424 pthread_mutex_lock(&l->lock);
32425 l->waiting_writers++;
32426 pthread_cleanup_push(waiting_writer_cleanup, l);
32427 while (l->lock_count != 0)
32428 pthread_cond_wait(&l->wcond, &l->lock);
32429 l->lock_count = -1;
32430 /*
32431 * Note the pthread_cleanup_pop executes
32432 * waiting_writer_cleanup.
32433 */
32434 pthread_cleanup_pop(1);
32435 }

i have yet to see a posix program which would use TWO separate
handlers so that

a) 1st handler - restore invariants
b) 2nd handler - release associated lock

**in the handling of cancelable waits**

the "standard approach" is much clear and less error
prone than scoped locking plus another 'handler', IMHO.

fyi..

32878 A side effect of acting on a cancelation request while a thread is
blocked on a condition variable
32879 is to re-acquire the mutex before calling any of the cancelation
cleanup handlers. This is done in
32880 order to ensure that the cancelation cleanup handler is executed in
the same state as the critical
32881 code that lies both before and after the call to the condition wait
function. This rule is also
32882 required when interfacing to POSIX threads from languages, such as
Ada or C++, which may
32883 choose to map cancelation onto a language exception; this rule
ensures that each exception
32884 handler guarding a critical section can always safely depend upon the
fact that the associated
32885 mutex has already been locked regardless of exactly where within the
critical section the
32886 exception was raised. Without this rule, there would not be a uniform
rule that exception
32887 handlers could follow regarding the lock, and so coding would become
very cumbersome.
32888 Therefore, since some statement has to be made regarding the state of
the lock when a
32889 cancelation is delivered during a wait, a definition has been chosen
that makes application
32890 coding most convenient and error free.

regards,
alexander.