Constraints When Using Locks

When adding locks in a module it is important to observe these constraints:

• Avoid holding module private locks across calls to putnext(9F), since the module might be reentered by the same thread that called putnext(9F), causing the module to try to acquire a lock that it already holds. This can cause kernel panic.

• Do not hold module private locks, acquired in put or service procedures, across the calls to qprocson(9F) or qprocsoff(9F). Doing this causes deadlock, since qprocson(9F) and qprocsoff) wait until all threads leave the inner perimeter.

• Similarly, do not hold locks, acquired in the timeout(9F) and bufcall(9F) callback procedures, across the calls to untimeout(9F) or unbufcall(9F). Doing this causes deadlock, since untimeout(9F)and unbufcall(9F) wait until an already executing callback has completed.

The first restriction makes it hard to use module private locks to presere message ordering. MT STREAMS perimeters is the preferred mechanism to preserve message ordering.