From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6267 invoked by alias); 21 Feb 2006 09:55:25 -0000 Received: (qmail 6175 invoked by uid 22791); 21 Feb 2006 09:55:24 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-35.mail.demon.net (HELO anchor-post-35.mail.demon.net) (194.217.242.85) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 09:55:22 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1FBUEe-0006t3-GD; Tue, 21 Feb 2006 09:55:08 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 726AD35EA6; Tue, 21 Feb 2006 09:55:06 +0000 (GMT) To: "Robert Bryce" Cc: ecos-discuss@ecos.sourceware.org References: <000e01c63669$092c4500$6500a8c0@Burnt> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Tue, 21 Feb 2006 09:55:00 -0000 In-Reply-To: <000e01c63669$092c4500$6500a8c0@Burnt> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s... X-SW-Source: 2006-02/txt/msg00209.txt.bz2 "Robert Bryce" writes: > Just jumping in here...just a private email... I've copied my response to the list since I believe it may be of interest to the rest of the community. > > > > > Nick> In eCos device drivers are responsible for their own > > > Nick> concurrency control. While some drivers might be able to > > > Nick> cope with two threads executing in them concurrently, most > > > Nick> cannot. They must therefore implement some sort of mutual > > > Nick> exclusion to serialize the threads. By remarkable > > > Nick> coincidence, a mutex does exactly the right thing. > [...] > > > Nick> A semaphore just would not work in this situation. > > I disagree. Wasn't there a famous paper decades ago that proved that > mutexes could be implemented with semaphores and vice versa? If so (and it > is), then they provide equal functionality and either/or could be used. > Then you look at the implementation advantages (not features) to choose what > to use. While there are both semaphore and mutex+cv implementations of all the standard synchronization examples (producer/consumer, resource management etc.), the semaphore versions tend to be tricky and usually require a couple of pages of explanation. Mutex+cv usually permits a very straightforward implementation of any synchronization activity. Semaphores are also lacking some features that are useful in real time systems. Without a concept of an owner they cannot participate in priority inheritance or similar protocols. Semaphores are independent of each other and it is difficult to implement a wait-for-something-to-happen thread queue without opening yourself up to deadlock or races -- much of the trickiness is aimed at working around this. Mutex+cv on the other hand makes such things simple with the linkage between condition variables and a mutex and the semantics of the condition variable wait operation. If I had my way, mutexes and condition variables would be the only synchronization primitives available in the OS. > > From a real time point of view, IO should be performed at the priority > > of the requesting thread. > > Alright, this is what spurred my email. Is/how much is eCos actually > real-time? Real-time scheduling (hard or soft) (guarantee-oriented - where > a thread says it needs so many cycles of execution time to complete by a > specific real time) is NOT priority-based (performance-oriented) scheduling. > Honestly, I haven't dived too deep into eCos (just enough to play on my > iPaq), but I've come across other so-called real-time systems that really > weren't - they just played with thread priorities to let certain threads > exhibit real-time characteristics, or appear to be by chance real-time. eCos is just as real time as its main rivals: VxWorks, ThreadX, pSOS etc. I have always resisted describing eCos as hard real time, although it is quite possible to get hard response times with care. In general, the OS on its own is not real time, only an entire system, OS+application, can be described as real time. All an RTOS designer can do is select data structures and algorithms that permit a real time system to be built. A real time OS cannot make non-real time code become real time. A good example is the BSD TCP/IP stack, which was never intended to be used in a real time system, all we can do in eCos is to ensure that whatever the stack does, it doesn't interfere with the real time components of the application. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts Visit us at ESC Silicon Valley, April 4-6 2006, Booth 2044 San Jose McEnery Convention Center http://www.embedded.com/esc/sv -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss