Re: [ECOS] Deadlock scenario on close() in io/fileio

[Nick Garnett <nickg at ecoscentric dot com>]

Rutger Hofman <rutger@cs.vu.nl> writes:

> Nick Garnett wrote:
> > Is YAFFS recursively calling back into its own entrypoints? Or is it
> > calling a different filesytem? I hope the latter, it should be using
> > it's own internal interfaces to do anything else.
> 
> You are absolutely right. The second I/O is caused by a trace print to
> stdout from YAFFS.

I would suggest that any trace prints use diag_printf() rather than
stdio. diag_printf deliberately works at a very low level to avoid any
issues like this.

> 
> >> I think there are a few possible solutions:
> >> 1) a full-fledged continuation mechanism where all locks are released
> >> when a layer is left;
> >> 2) allow fdlock to be grabbed recursively, as in Java-style
> >> synchronized locking;
> > These both look horrible. Recursive mutexes are evil and are to be
> > resisted at all costs -- they are generally a quick workaround for
> > something that should be solved with a bit more thought.
> 
> You should tell the Java designers... :-)

Frankly, I'm not surprised that Java needs recursive mutexes. I would
expect to find them in C# and Visual Basic too. :-)

> 
> This is solution 3). It works for my test program. Thanks! I'll strip
> out my recursive mutexes again.

Good. I'll check it in.

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss