This is the mail archive of the ecos-discuss@sourceware.org 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: Deadlock scenario on close() in io/fileio


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


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