Greetings, a more generic follow-up question on dispatching soft-interrupts from hi-level (hard) interrupts: as described in the Sun documentation at several places (device driver tutorial, or http://developers.sun.com/solaris/articles/interrupt_handlers.html), the softintr and hardintr handler synchronize via a "is_running" flag, protected by a mutex.
If 'is_running' is true, the softintr handler will not be triggered (again). However, what about the race between the softintr handler setting 'is_running' to false (and releasing the lock), and the time that it is actually returning from the handler function and is declared "non-running", so that it can be triggered again? The hardintr handler may come in in this very moment, assume the softintr handler is not running, trigger it, get EPENDING and quits => an interrupt would be lost. Admitted, the race is small - or am I wrong? Additionally, what is best practise for the work queue maintained between these two handlers? As we can not allocate memory within the hardirq-handler, we need to use some statically allocated queue. Assuming the worst, this queue could be full when the hardintr handler wants to queue something => interrupt lost. We are trying to prevent this by letting the softintr handler increase the number of available queue entries depending on a low-water mark, but still not bullet proof, or is it? Joachim -- Joachim Worringen, Software Architect, Dolphin Interconnect Solutions phone ++49/(0)228/324 08 17 - http://www.dolphinics.com _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
