This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Deadlock scenario on close() in io/fileio
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Thu, 11 Dec 2008 12:45:04 +0100
- Subject: Re: [ECOS] Deadlock scenario on close() in io/fileio
- References: <4940ED76.9040800@cs.vu.nl>
Rutger Hofman wrote:
Good morning list,
I ran into a deadlock with io/fileio on invoking close(fd) in
io/fileio/current/src/fd.cxx.
[snip]
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;
3) check if this is the only occurrence of this deadlock scenario, and
check if the lock can be released in fp_ucount_dec without impairing
atomicity
1) is a lot of work
2) sounds good to me; the mutex.cxx type could be subclassed
I quickly made a Cyg_Recursive_Mutex that has a Cyg_Mutex field (so
there is no need to make lock()/unlock()/trylock() virtual), and that
allows recursive locking. This also makes the deadlock go away.
Please advise:
- do you agree recursive locking is a good solution?
- should the Cyg_Recursive_Mutex be in kernel/sync or in io/fileio?
- should I submit a patch? Or do you want to investigate this issue at
leasure (as I would)?
The question on the other locks in io/fileio remains open for me.
Rutger
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss