This is the mail archive of the ecos-bugs@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 20002] New: Add ASSERTs to enforce Synchronization Level


http://bugs.ecos.sourceware.org/show_bug.cgi?id=20002

           Summary: Add ASSERTs to enforce Synchronization Level
           Product: eCos
           Version: unknown
          Platform: Other
        OS/Version: Other
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Other
        AssignedTo: nickg at ecoscentric dot com
        ReportedBy: nobody at cygnus dot com


> Jesper Skov wrote:
> > 
> > I suggest we add a new (configurable) ASSERTion group on
> > synchronizers, checking that they are not called from ISRs or DSRs.
> >
> >mutex_lock()
> >{
> >#ifdef SYNCHRONIZER_POLICING
> >     ASSERT(0 == is_ISR/DSR, "This is the captain speaking... We are
> >going down....");
> >#endif
> 
> Inferring from the existence of the ifdef, I assume you noticed that,
> although unlikely, the user may know the mutex isn't locked at the time of
> the DSR, in which case I believe it would be ISR/DSR safe.

No, I think it's not that.

Then they can just wade in without locking the mutex, or use trylock().
OK, this won't apply if the DSR or (perish the thought) an ISR calls into a
routine that itself locks the mutex.  But I think such behaviour is illegal
anyway, really.

> So if you do want to put this in (and on balance I think it would be good),
> I agree there should indeed be a (publicised) config option controlling it.

Well it should definitely be OFF by default; there is considerable cost in
implementing the support for this, in all ISR code!  The ISR variable must
be inc/dec not just set/unset to handle recursive interrupts (or set/unset
along with switching stacks on those architectures) - all with interrupts
off for atomicity.  In all HALs!

I agree that this would be a nice thing for the kernel primitives, turned
off by default, and set up explicitly so that if a HAL ignores this
feature, all is well.  So the kernel provides those variables, initialized
to zero, and if the HAL never diddles them, the asserts will not fire.
This needs commenting very clearly.

	- Huge


---------------------------------------------------------------------------

Originator:
Jesper Skov

Organization:
CS

Audit-Trail:
Responsible-Changed-From-To: alexs->hmt 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Wed Apr 28 11:27:06 PDT 1999 
Responsible-Changed-Why:  
Hi Hugo 

Could you please take control of this one and generate an entry in the README 
if applicable. Jesper is going to be pretty busy tomorrow testing the EPROM cycle and I doubt will have much time.  If any coding changes are necessary, 
then you can pass back to Jesper if you wish for fixing after the release. 

Thanks 
-- Alex 


From: Hugo Tyson <hmt at cygnus dot co dot uk>
To: alexs at cygnus dot co dot uk
Cc: bugs at cygnus dot com
Subject: Re: ecc/20002
Date: Wed, 28 Apr 1999 19:39:26 +0100

 > Synopsis: Add ASSERTs to enforce Synchronization Level
 > 
 > Could you please take control of this one and generate an entry in the
 > README if applicable. Jesper is going to be pretty busy tomorrow testing
 > the EPROM cycle and I doubt will have much time.  If any coding changes
 > are necessary, then you can pass back to Jesper if you wish for fixing
 > after the release.
 
 What?  This is a nice thing to have at some stage, not worth doing
 _anything_ for for this release.  The doc forbids quite clearly doing the
 stupid things that these changes would detect; the point is that we will
 nightly-test some configurations that enable that detection.
 
 Don't worry about it...
 
 	- Huge
 
 

From: "Alex Schuilenburg" <alexs at cygnus dot co dot uk>
To: "Hugo Tyson" <hmt at cygnus dot co dot uk>
Cc: <bugs at cygnus dot com>
Subject: RE: ecc/20002
Date: Wed, 28 Apr 1999 19:50:03 +0100

 Hi Hugo
 
 [deleted] 
 > What?  This is a nice thing to have at some stage, not worth doing
 > _anything_ for for this release.  The doc forbids quite 
 > clearly doing the
 > stupid things that these changes would detect; the point is 
 > that we will
 > nightly-test some configurations that enable that detection.
 > 
 > Don't worry about it...
 
 Thanks :-)  I am getting carried away here.
 
 I will pass back to Jesper right?
 
 Cheers
 -- Alex

Unformatted:
Originator:  

page: www.cygnus.com/product/ecc-pr.html

Send_PR_form: Sent_from_www.cygnus.com



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]