From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andy Simpkins" To: "eCos Discuss" Subject: RE: [ECOS] mutex operation Date: Tue, 03 Jul 2001 07:25:00 -0000 Message-id: References: X-SW-Source: 2001-07/msg00075.html 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" 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 >