This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: problem with cyg_thread_release
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Christoph Csebits <christoph dot csebits at frequentis dot com>
- Cc: ecos discuss list <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 8 Jan 2004 18:38:47 +0100
- Subject: Re: [ECOS] problem with cyg_thread_release
- References: <20040108164224.A14630@frequentis.com>
On Thu, Jan 08, 2004 at 04:42:24PM +0100, Christoph Csebits wrote:
> hi,
>
> there is a problem with cyg_thread_release():
>
> Scenario: thread A is waiting to get a mutex in cyg_fp_free() in
> file ./io/fileio/current/src/fd.cxx. Now thread A is released.
>
> FILEIO_MUTEX_LOCK returns with false, which is not handled and
> further FILEIO_MUTEX_UNLOCK operates on a mutex, which the
> thread does not own -> assertion.
Hopefully Nick will come along and correct me if im wrong.
I would not say this is a problem with cyg_thread_release() itself,
but more of a problem with expecting it to work in uncontrolled
situations. For this to work reliably all code everywhere has to check
if it was released from a blocking operation without being
successful. It then has to try to recover from this situation. For the
example given it just has to return -EINTR. But in other cases the
code may have to actually undo what it has already done in order to
leave the system in a consistent state. It may even need to get some
other mutex and so risk blocking again. Handling all these cases would
both add a lot of bloat which most people don't need and also be very
error prone since its hard to test.
I'd suggest you only use cyg_thread_release() on a thread when you
know exactly where its blocked and can ensure it will do the right
thing after being released.
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss