This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: mutex operation
- To: "eCos Discuss" <ecos-discuss at sourceware dot cygnus dot com>
- Subject: RE: [ECOS] mutex operation
- From: "Andy Simpkins" <Andy dot Simpkins at TardisMobile dot com>
- Date: Tue, 3 Jul 2001 15:19:27 +0100
- Reply-To: Andy dot Simpkins at TardisMobile dot com
Thanks,
I agree that I can't use cyg_mutex_lock and cyg_mutex_unlock, but surly
there has to be a method of sharing a resource for use by a DSR and thread?
I could in this instance fall back to getting a thread to do the job passing
data through a message box, but it would mean that I need to create yet
another thread to do nothing more complex than write a few bits to
hardware....
Any suggestions would be most welcome
Andy
> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Hugo Tyson
> Sent: 03 July 2001 14:56
> To: eCos Disuss
> Subject: Re: [ECOS] mutex operation
>
>
>
> "Andy Simpkins" <Andy.Simpkins@TardisMobile.com> writes:
> > Just a short question on the use of Mutexes as the
> documentation does not
> > seem clear...
> >
> > If I use a mutex to protect a resource in both a thread and inside a DSR
> > will the eCos scheduler promote the thread's priority to greater than
> > that of the DSR in the event that the thread has locked the resource and
> > the DSR is waiting on that resource?
>
> Nope. You must not use a mutex within a DSR, because attempting
> to acquire
> the mutex can cause the caller to block. DSRs must not block.
>
> Priority does not really apply to DSRs and interrupts:
>
> All interrupts (ISRs) (when enabled and unmasked) have higher
> priority than
> all DSRs and all threads.
> All DSRs have higher priority than all threads.
> Threads have numerical priority amongst themselves.
> Depending on hardware implementation, interrupts might have a numerical
> proprity amongst themselves - more often it is fixed by the hardware.
> DSRs are just all run in arbitrary order as soon as possible, as
> soon as it
> is safe to do so.
>
> HTH,
> - Huge
>