* Bosko Milekic <[EMAIL PROTECTED]> [010117 14:35] wrote:
>
> Alfred Perlstein wrote:
>
> > Which means we don't have to drop the lock over the socket unless
> > we'd block on allocation.
>
> No. You'd still have to drop it for now. Remember? (Last commit to
> uipc_mbuf.c). You have to drop it because of the problem you may have if
> Giant is gotten before your sockbuf/socket lock. In the allocation, you may
> be acquiring Giant again. I don't know the exact semantics, but if you at
> some point may grab the sockbuf/socket lock without already holding Giant and
> call the allocation routine, you're opening the door for deadlock.
The rest of the patches unwind giant on entry into the socket layer
so grabbing Giant shouldn't be a problem.
> > Matt, is this what you intended for it to do? So far I've only
> > seen it used to avoid races, but not to optimize out mutex
> > aquire/release.
>
> I've only seen it to be useful to avoid races. If you're holding a lock
> and you need to sleep but if you drop the lock before you actually switch you
> may get woken up and never find out, thus still going to sleep. With the
> asleep you could hold the lock and place yourself on the sleep queue such
> that when you drop the lock and call await, you'll find out if you've gotten
> awoken (you'll be removed from the sleep queue). With the interlocking with
> sched_lock now down in msleep(), this "feature" of asleep/await is useless.
Read the rest of my posts, the ones not cc'd to everyone, just Matt and
-arch.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
