From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11452 invoked by alias); 29 Nov 2003 19:40:20 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 11440 invoked from network); 29 Nov 2003 19:40:16 -0000 Received: from unknown (HELO lapdancer.baythorne.internal) (193.237.130.41) by sources.redhat.com with SMTP; 29 Nov 2003 19:40:16 -0000 Received: from lapdancer.baythorne.internal ([127.0.0.1]) by lapdancer.baythorne.internal with esmtp (Exim 4.14) id 1AQAws-000488-Mc; Sat, 29 Nov 2003 19:40:10 +0000 From: David Woodhouse To: Nick Garnett Cc: ecos-discuss@sources.redhat.com In-Reply-To: References: <000001c3b4c7$023894e0$7407a8c0@figuier> <1070018075.10048.29.camel@hades.cambridge.redhat.com> <1070018876.10048.35.camel@hades.cambridge.redhat.com> <1070035746.13188.17.camel@hades.cambridge.redhat.com> Content-Type: text/plain Message-Id: <1070134810.15826.14.camel@lapdancer.baythorne.internal> Mime-Version: 1.0 Date: Sat, 29 Nov 2003 19:40:00 -0000 Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] RE : [ECOS] Is JFFS2 thread-safe? X-SW-Source: 2003-11/txt/msg00436.txt.bz2 On Sat, 2003-11-29 at 15:47 +0000, Nick Garnett wrote: > 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. OK. That was a brain fart on my part -- in Linux without preemptive scheduling, you mustn't sleep with spinlocks held, and with preemptive scheduling a spin_lock() prevents preemption... I was applying that same 'knowledge' and thinking that preemption would lead to deadlock as it would under Linux. That's obviously bogus. We use spin_lock() in JFFS2 as a short-lived lightweight mutex; we could map it to eCos spinlocks or mutexes as you see fit -- as long as it's mapped to _something_ in the case where preemptive scheduling happens, I'm happy. Only in the absence of preemption is it safe in its current 'do {} while(0)' form. Having tidied up most of the interface between core JFFS2 code and the eCos-specific parts, the latter could really do with some TLC from someone who knows eCos a lot better than I do. -- 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