From: "Phil Frisbie, Jr." <phil@hawksoft.com>
To: limin.fu@ircc.it
Cc: pthreads-win32@sources.redhat.com
Subject: Re: A question about thread cancellation
Date: Thu, 29 Sep 2005 17:10:00 -0000 [thread overview]
Message-ID: <433C2017.3040504@hawksoft.com> (raw)
In-Reply-To: <32883.130.192.136.198.1128010379.squirrel@130.192.136.198>
Fu Limin wrote:
> Hello,
>
> I have a question on thread cancellation, which is not specifically
> relevant to pthread-win32, I hope you will not mind if I post it in this
> mailling list.
>
> In my program, there is a global mutex and a condition variable. And there
> are several threads wait on this cond.var. under the protection of this
> mutex. When I cancel one of the threads, I found there is a trouble in the
> thread clean up. Because the mutex can be in either locked or unlocked
> state. And if it is in locked state, I can't tell if it is locked by
> another thread, or it gets the locked state from the cancellation point
> pthread_cond_wait()! If it is locked by another thread, I should do
> nothing on it, but if it gets the locked state by returning from
> pthread_cond_wait() due to cancellation, I should unlock it in the clean
> up.
>
> So the problem is, how can I know, in the clean up, when should I unlock
> the mutex, and when not? Did any body have experienced similar problem?
> Does anybody have any hints on this?
In my opinion it is EVIL (or at least bad programming) to cancel threads. It is
better to architect your code so that you can request a thread to exit on it's own.
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
prev parent reply other threads:[~2005-09-29 17:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-29 16:13 Fu Limin
2005-09-29 17:10 ` Phil Frisbie, Jr. [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433C2017.3040504@hawksoft.com \
--to=phil@hawksoft.com \
--cc=limin.fu@ircc.it \
--cc=pthreads-win32@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).