Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Jan Kiszka wrote:
 > >  > Gilles Chanteperdrix wrote:
 > >  > > Jan Kiszka wrote:
 > >  > >  > As the #ifdef forest was cut down, I once again looked at 
 > > xnlock_put.
 > >  > >  > Why do you have this safety check for the owner also in production 
 > > code?
 > >  > > 
 > >  > > Because only one broken xnlock_put could entail a chain reaction of
 > >  > > broken xnlock sections with code on multiple CPU violating critical
 > >  > > sections. With the test, we prevent the chain reaction. But I agree 
 > > this
 > >  > > check should not be silent.
 > >  > 
 > >  > When there is a bug, then there is bug and we are hosed. That's why we
 > >  > have debug checks for finding such cases in advance. Here I was talking
 > >  > about such a debug check in a hot path on a _production_ system, and
 > >  > that check even had no fault recovery. That appeared pointless to me.
 > >  > 
 > >  > Just to avoid misunderstandings: This version is not different from the
 > >  > old one if XENO_OPT_DEBUG_NUCLEUS is on, the switch which was introduced
 > >  > to cover specifically lock debugging.
 > >  > 
 > >  > Do you have an idea for some cheap fault recovery for broken locking
 > >  > that we should put in instead?
 > > 
 > > The fault recovery is to leave the xnlock untouched, in order to avoid
 > > the chain reaction I was talking about.
 > 
 > But you may later deadlock on it when trying to reacquire this
 > unbalanced lock. It can help against double releases, granted. Still,
 > such cases should be eliminated _ahead_ of release via review, so that
 > one can finally go for the fast unchecked version in the matured system.

A deadlock is far easier to spot than a violated critical section.

 > 
 > > Anyway, I think even production
 > > code should contain some sanity checks, and this one looks cheap.
 > 
 > I'm fine with a simple check as well. But there should be an _option_
 > for such checks, even more if they are supposed to be inlined.
 > Uninlining reduces this pressure, but it still adds text size to the hot
 > path.

No, no option, some sanity checks should be unavoidable, this one is
such a check. We will probably never agree I guess.

-- 


                                            Gilles Chanteperdrix.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to