Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...

[Nick Garnett <nickg at ecoscentric dot com>]

"Robert Bryce" <rob@mobilia-os.com> 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