Date: Wed, 22 May 2013 11:05:54 -0400 From: John Baldwin <jhb@freebsd.org> To: Orit Moskovich <oritm@mellanox.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: FreeBSD spinlock - compatibility layer Message-ID: <201305221105.55093.jhb@freebsd.org> In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D3CD8@MTLDAG01.mtl.com> References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305220859.32948.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D3CD8@MTLDAG01.mtl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, May 22, 2013 9:48:00 am Orit Moskovich wrote: > From the mutex man page " By default, MTX_DEF mutexes will context switch when they are already held." > How is sleeping forbidden, but blocking on a mutex that might context switch is ok? Because they are different. When you block on a lock you propragate your priority to the lock holder and will resume execution if you are more important as soon as the holder drops the lock. In other words, you are going to make forward progress. With "event" sleeps like *sleep() and condition variables, there is no owner to propagate priority to, and the sleep may very well be waiting for some arbitrary event (such as the arrival of a network packet or completion of an I/O request), so there is not the same guarantee of making forward progress. The other half of this that keeps this true is that you are not permitted to perform "event" sleeps while holding a mutex. You have to drop the lock while you wait which frees any threads waiting for the lock to run. When you block on a mutex the only thing you are ever waiting on is CPU time for either yourself or the lock holder to run. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305221105.55093.jhb>