[illumos-Developer] webrev: 1039 /usr/lib/smbsrv/smbd preventssuspend
Garrett D'Amore
garrett at nexenta.com
Fri May 27 12:29:21 PDT 2011
In general, I prefer cv_broadcast unless I have done a specific analysis and have performance issues. The reason is that if you have multiple threads using the same cv it is possible to wake the "wrong" waiter with just signal, leading to a potential lost wakeup. Hence I view bcast as safer unless you are careful with your usage.
-- Garrett D'Amore
On May 27, 2011, at 11:02 PM, "Gordon Ross" <gordon.w.ross at gmail.com> wrote:
> 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
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
More information about the Developer
mailing list