> Well, I hate nested locks when it comes to real-time, but in this case I
> really found no simpler approach. There is the risk of deadlocks via
> IRQ: xnintr_shirq::lock -> handler -> nklock vs.
> Application: nklock -> xnintr_attach/detach -> xnintr_shirq::lock,
it's also relevant for the current code - xnintr_attach/detach() must
not be called while holding the 'nklock'.
I think, your approach should work as well.. provided we have only a
single reader vs. a single writter contention case, which seems to be
the case here ('intrlock' is responsible for synchronization between
xnintr_attach/detach()).. your approach does increase a worst case
length of the lock(&intrlock) --> unlock(&intrlock) section... but
that's unlikely to be critical.
I think, the patch I sent before addresses a reported earlier case
with xnintr_edge_shirq_handler().. but your approach does make code
shorter (and likely simpler), right? I don't see any problems it would
possibly cause (maybe I'm missing smth yet :)
Xenomai-core mailing list