Re: first sight

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:
> >
> > http://groups.yahoo.com/group/boost/message/22836
> >
> > 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:
> >
> > http://groups.yahoo.com/group/boost/message/22881
> >
> > 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 
can't
> 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:

 http://www.ibm.com/servers/eserver/zseries/software/sa
 (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 
 pthreads-win32.

regards,
alexander.

----
Sent by:	rpj_at_[hidden]
To:	Alexander Terekhov/Germany/IBM_at_IBMDE
cc:	 
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.
Thanks.
Ross
Alexander Terekhov wrote:
>
> Hi Ross,
>
> I think that we might have a problem with respect to:
>
> http://groups.google.com/groups?as_umsgid=3A65A492.6251AA52%
40compaq.com
>
> ">        pthread_cancel(tid);
>  >        pthread_cancel(tid); /* should this fail? */
>  >        pthread_join(tid, NULL);
>
>  Cancel just posts a pending cancel. Once the cancellation unwind 
starts,
>  cancelability is disabled for the duration. Therefore, either 
you're
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  just re-posting the pending cancel (which does nothing) or posting 
a
>  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:
http://public.ise.canberra.edu.au/~rpj/
| AUSTRALIA                   |
+-----------------------------+