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
> 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
> understand what I read there, and the comment above is a bit
> for me to understand.
"...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 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 | +-----------------------------+
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk