[illumos-Developer] webrev: 1039 /usr/lib/smbsrv/smbd prevents suspend

[Gordon Ross]

On Fri, May 27, 2011 at 2:59 PM, Eric Schrock <eric.schrock at delphix.com> wrote:
>
> FYI, for cv_signal vs. cv_broadcast discussion, and a good discussion of
> concurrency issues in general, check out Bryan's Queue article:
>     http://portal.acm.org/citation.cfm?doid2=1454456.1454462
> Or the shorter CACM version (no ACM login required):
>     http://portal.acm.org/citation.cfm?doid2=1400214.1400227
> The over-dependence of cv_broadcast() (or the java equivalent notifyAll) can
> lead to some nasty performance pathologies.
> 1. If you are communicating state change, generally use broadcast.   All
> consumers need to be made away of the state change and act on it
> accordingly.
> 2. If you are communicating resource availability, generally use signal.
>  Otherwise, all waiters will wake up, one will win the mutex race,
> (presumably) consume the available resources, and drop the lock.  Everyone
> else will wake up, fight for the lock, only to find out there is no work to
> do, and go to sleep.
> - Eric
> --
> Eric Schrock
> Delphix
> 275 Middlefield Road, Suite 50
> Menlo Park, CA 94025
> http://www.delphix.com
>

Yes, that's the well known "thundering herd" problem.

In this case, there's only one waiting process to wake,
so it doesn't matter which we use.
(and I didn't feel like changing it:)

Gordon