This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Nested mutex problem (fdlock in fd.cxx)
- From: "Jurica Baricevic" <jura at INTESIS dot hr>
- To: "Gary Thomas" <gary at chez-thomas dot org>
- Cc: "eCos Discussion" <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 20 Jun 2002 09:30:20 +0200
- Subject: RE: [ECOS] Nested mutex problem (fdlock in fd.cxx)
> Garry Thomas wrote (Wednesday, June 19, 2002 17:56):
> On Wed, 2002-06-19 at 09:29, Jurica Baricevic wrote:
> > Hi.
> >
> > I have found a small problem with mutex 'fdlock' in
> > 'io/fileio/current/src/fd.cxx' for one particular case. It
> seems that it is
> > possible to create nested mutex lock case in a file system
> implementation.
> > Specifically, call to close() function locks 'fdlock', which
> then may lead
> > to another lock by calling 'printf' in lower layers (within the
> particular
> > file system implementation). This is because 'printf' may get to
> > cyg_fp_get() function, which is also locking 'fdlock'.
> Unfortunately, eCos
> > does not support nested mutexes.
> >
> > It may sound odd that 'printf' is used within file system functions.
> > Nevertheless, it may be quite useful for reporting errors in low level
> > functions (egg. bad block warning, write protect notification,
> etc.). It is
> > worth to mention that I am debugging some proprietary file system under
> > eCos.
> >
>
> Because of situations like this, we recommend using 'diag_printf()'
> for debug/error messages.
>
:-)
Thanks. Don't know how could I overlook this.
Anyway, does this mean I cannot log errors to other devices/filesystems
(egg. via DEVIO) in this particular case?
Best regards,
Jura
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss