This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem with cyg_thread_release


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]