Boost logo

Boost :

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-17 03:56:28

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "terekhov" <terekhov_at_d...>
> > Just go back to:
> >
> >
> >
> > and this time just do a search on "mutex".
> Yes, it locks a mutex in order to implement cancellation
protection. Why
> isn't it just accessing TLS at this point?

  * Lock for async-cancel safety.
  */" ^^^^^^^^^^^^^^^^^^^

to prevent "double-" cancel. fyi.. you might
also want to have a look at the attached message
(with respect to the pthread-win32 code posted).

> It seems strange that other
> threads should be contending for this thread's notion of whether
> cancellation is disabled.
> >
> > The right answer is awaiting you here:
> >
> >
> >
> > one more hint: it will throw AND "protect" but it won't be
> > a "mutex", in the sense of "pthread_mutex_t" class objects.
> This one just looks like another of your mysterious links to me. I
> understand what I read there, and the comment above is a bit
too "hint-y"
> for me to understand.

pthread_mutex_timedlock() Rationale:

"...The Condition Wait implementation effectively
 substitutes the pthread_cond_timedwait() function
 (which is currently timed out) for the desired
 pthread_mutex_timedlock( ). Since waits on condition
 variables currently do not include protocols which
 avoid priority inversion, this method is generally
 unsuitable for realtime applications because it does
 not provide the same priority inversion protection
 as the untimed pthread_mutex_lock( ). Also, for any
 given implementations of the current mutex and
 condition variable primitives, this library implementation
 has a performance cost at least 2.5 times that of the
 untimed pthread_mutex_lock() even in the case where the
 timed mutex is readily locked without blocking (the
 interfaces required for this case are shown in bold).
 Even in uniprocessors or where assignment is atomic,
 at least an additional pthread_cond_signal ( ) is
 required. pthread_mutex_timedlock( ) could be implemented
 at effectively no performance penalty in this case because
 the timeout parameters need only be considered after it
 is determined that the mutex cannot be locked immediately.
 Thus it has not yet been shown that the
 full semantics of mutex locking with
 timeout can be efficiently and reliably
 achieved using existing interfaces."

 (i.e. condition variables or busy-waiting)

 Perhaps you just contact Butenhof if you still
 have any more "why" question wrt mutex locking
 and cancelation. All of my knowledge comes from
 his book (2 volumes ;) and the standard. I am
 just an *application* programmer here:
 (we are looking now at other clusters/porting ;)

 and I have nothing to do with PTHREADS-impls
 other than just a few small contributions to


Sent by:	rpj_at_[hidden]
To:	Alexander Terekhov/Germany/IBM_at_IBMDE
Subject:	Re: pthreads-win32/cancel.impl
Hi Alexander,
I think you're right. There is also some possible contention
between the cancelation routines and the thread destroy
routines that needs fixing. This is a good time to look
at both issues.
Alexander Terekhov wrote:
> Hi Ross,
> I think that we might have a problem with respect to:
> ">        pthread_cancel(tid);
>  >        pthread_cancel(tid); /* should this fail? */
>  >        pthread_join(tid, NULL);
>  Cancel just posts a pending cancel. Once the cancellation unwind 
>  cancelability is disabled for the duration. Therefore, either 
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  just re-posting the pending cancel (which does nothing) or posting 
>  pending cancel on a thread that should have cancelability disabled
>  (which does nothing). Sure, it's legal, but not very interesting"
> Perhaps someone who contributed the cancel.impl could also
> add a fix? (unless I am missing something and we have no
> problem... then I am sorry for annoyance)
> regards,
> alexander.
| Ross Johnson            |   | "Come down off the cross
| Management & Technology |___|  We can use the wood" - Tom Waits
| Building 11                 |
| University of Canberra      | eMail: rpj_at_[hidden]
| ACT    2601                 | WWW:
| AUSTRALIA                   |

Boost list run by bdawes at, gregod at, cpdaniel at, john at