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.
Xenomai-core mailing list