public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] mutex operation
@ 2001-07-03  6:45 Andy Simpkins
  2001-07-03  6:57 ` Hugo Tyson
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Simpkins @ 2001-07-03  6:45 UTC (permalink / raw)
  To: eCos Disuss

Hi there,

Just a short question on the use of Mutexes as the documentation does not
seam 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?


Andy



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] mutex operation
  2001-07-03  6:45 [ECOS] mutex operation Andy Simpkins
@ 2001-07-03  6:57 ` Hugo Tyson
  2001-07-03  7:25   ` Andy Simpkins
  0 siblings, 1 reply; 4+ messages in thread
From: Hugo Tyson @ 2001-07-03  6:57 UTC (permalink / raw)
  To: eCos Disuss

"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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [ECOS] mutex operation
  2001-07-03  6:57 ` Hugo Tyson
@ 2001-07-03  7:25   ` Andy Simpkins
  2001-07-03  8:05     ` Andy Simpkins
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Simpkins @ 2001-07-03  7:25 UTC (permalink / raw)
  To: eCos Discuss

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
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [ECOS] mutex operation
  2001-07-03  7:25   ` Andy Simpkins
@ 2001-07-03  8:05     ` Andy Simpkins
  0 siblings, 0 replies; 4+ messages in thread
From: Andy Simpkins @ 2001-07-03  8:05 UTC (permalink / raw)
  To: eCos Discuss

Doh!

there is a perfectly good example in the serial port handling...

thread locks resource using a mutex
thread disables DSRs
thread does it's thing with the resource
thread re-enables DSRs
thread unlocks resource' mutex

thus no other thread can access the resource
DSRs can not access the resource whilst it has been grabbed by a thread
(because they are disabled)

Andy


> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [ mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Andy Simpkins
> Sent: 03 July 2001 15:19
> To: eCos Discuss
> Subject: RE: [ECOS] mutex operation
>
>
> 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
> >
>
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-07-03  8:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-03  6:45 [ECOS] mutex operation Andy Simpkins
2001-07-03  6:57 ` Hugo Tyson
2001-07-03  7:25   ` Andy Simpkins
2001-07-03  8:05     ` Andy Simpkins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).