This is the mail archive of the
ecos-bugs@sources.redhat.com
mailing list for the eCos project.
[Bug 20002] New: Add ASSERTs to enforce Synchronization Level
- From: bugzilla-daemon at ecoscentric dot com
- To: ecos-bugs at sources dot redhat dot com
- Date: Thu, 24 Apr 2003 17:29:38 +0100 (BST)
- Subject: [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.