Re: [ECOS] RE : [ECOS] Is JFFS2 thread-safe?

[Nick Garnett <nickg at ecoscentric dot com>]

David Woodhouse <dwmw2@infradead.org> writes:

> On Fri, 2003-11-28 at 11:27 +0000, David Woodhouse wrote:
> > +#ifdef CYGPKG_KERNEL
> > +#include <cyg/kernel/kapi.h>
> > +#define spin_lock(lock) cyg_scheduler_lock()
> > +#define spin_unlock(lock) cyg_scheduler_unlock()
> > +#define spin_lock_bh(lock) cyg_scheduler_lock()
> > +#define spin_unlock_bh(lock) cyg_scheduler_unlock()
> 
> Hmmm. I forgot eCos now had SMP support, and has its own spinlocks. 
> 
> Can't say I much like the idea of putting in a #define to call a C
> function which is a wrapper around a C++ class which in turn is a
> wrapper round the original HAL functions... or in fact in the common
> case is just a dummy counter which doesn't actually lock the scheduler
> to avoid preemption... is that intentional?

Well, most of that should collapse through the use of inline functions
and macros. Only the call to the C function should be real.

eCos spinlocks are different from Linux ones in any case. They are not
generally used as mutexes over shared data structures, we use actual
mutexes for that. eCos was not really designed to be SMP and the SMP
support is currently the minimum we need to get it to work. The
scheduler lock is a global all-threads, all-CPUs lock. We don't have a
per-thread preemption lock the way Linux does. The scheduler lock is
also bound up with the way that DSRs work and the whole interrupt
mechanism, so changing it transparently is probably not possible.

For these reasons, making spin_lock() et al use the scheduler lock is
probably a bad idea, it would have an effect on the whole system if
they were held for long periods of time.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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