“Adam Mallory” <amallory@qnx.com> wrote in message
news:de53aa$lag$1@inn.qnx.com…
Marty Doane wrote:
I happen to be in the 0.1% camp.The behavior of condition variables at thread cancelation was changed
between 6.2.1B and 6.3.0. Previously, the mutex guarding the condition
variable was left unlocked if a thread waiting on the condition variable
was canceled. Now this mutex is locked. My 6.2.1 application runs OK in
6.3.0 but deadlocks on shutdown. The solution is a rigorous use of
cleanup handlers to unlock the appropriate mutex.This is POSIX defined behaviour - it explicitly says that upon
cancellation, the mutex must be acquired before running the cleanup
handlers and canceling (the behaviour change is unfortunately not in the
migration notes - I’ll see if we can change that).
Thank you.
Additionally, the previous behaviour was to leave the mutex alone, not
ensure it was unlocked, so it’s state at the time of cancellation is
purely a function of the asynchronous nature of your application.
Agreed.
IMHO, the use of cleanup handlers to ensure shared resource sanity is good
programming practice regardless of the rules - especially when doing
thread cancellation.
Agreed. I have to confess that I learned some things during this experience
and our application is now more robust as a result.
Marty
–
Cheers,
AdamQNX Software Systems
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster