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. Anyway, I think even production
code should contain some sanity checks, and this one looks cheap.


                                            Gilles Chanteperdrix.

Xenomai-core mailing list

Reply via email to