This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Is JFFS2 thread-safe?
- From: David Woodhouse <dwmw2 at infradead dot org>
- To: Vincent Catros <Vincent dot Catros at elios-informatique dot fr>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 27 Nov 2003 00:27:25 +0000
- Subject: Re: [ECOS] Is JFFS2 thread-safe?
- References: <001601c3b3fe$52041450$7407a8c0@figuier>
On Wed, 2003-11-26 at 10:18 +0100, Vincent Catros wrote:
> Hello,
>
> Is JFFS2 thread safe?
> Some pieces of code make me think eCos implementation of JFFS2 was
> designed to be thread-safe while some other make me think it's not.
The core JFFS2 code is thread safe, assuming the Linux semaphore and
spinlock primitives are correctly translated into eCos mutexes and
preemption blocks. The bit that I haven't paid much attention to w.r.t.
locking is the inode cache handling in fs-ecos.c.
In fact, I suspect that is actually OK because we set the
CYG_SYNCMODE_FILE_FILESYSTEM flag and hence the fileio layer ensures
that only one file system method is invoked at a time. It would be
better to do our own locking and drop that flag though, since it makes
coordinating the locking with gcthread.c a little nicer.
Your underlying flash drivers may also need to be thread-safe, if you're
allowing concurrent calls into JFFS2 -- which I think we are; open and
close are serialised but read() and write() on two separate files can
happen simultaneously AFAICT.
JFFS2 will assume that it's perfectly OK to have one thread reading
while another is erasing or writing -- it's the responsibility of the
flash driver to make it work.
--
dwmw2
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss