Date: Wed, 17 Aug 2005 11:13:40 +0900 From: gnn@freebsd.org To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-arch@freebsd.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <m2pssdjoob.wl%gnn@neville-neil.com> In-Reply-To: <20050816162241.A74005@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <20050816051231.D66550@xorpc.icir.org> <20050816200010.GJ13959@cirb503493.alcatel.com.au> <200508161716.44597.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Tue, 16 Aug 2005 16:22:41 -0700,
luigi wrote:
>
> ok just for the records, the issue i had in mind is the release/acquire
> the mutex around some code that might cause a deadlock, not for the
> mutex ops per se, but for the need to make sure that the data
> structure is consistent before releasing the lock, and rechecking
> the state afterwards. Basically:
>
> 1 mtx_lock(&foo)
> 2 .. work on obj_foo
> 3 .. make obj_foo consistent
> 4 mtx_unlock(&foo)
> 5 f()
> 6 mtx_lock(&foo)
> 7 .. revalidate state of obj_foo
> 8 .. more work
>
> where f() is the call that might sleep or cause a deadlock.
> In cases where f() has a low probability of blocking, we could
> save a bit of work at runtime by writing the code as below:
>
> 1 mtx_lock(&foo)
> 2 .. work on obj_foo
> if (try_f_without_blocking() == EWOULDBLOCK) {
> 3 .. make obj_foo consistent
> 4 mtx_unlock(&foo)
> 5 f()
> 6 mtx_lock(&foo)
> 7 .. revalidate state of obj_foo
> }
> 8 .. more work
>
> (where try_f_without_blocking() is a version of f() that returns
> EWOULDBLOCK in case the 'other' lock is busy).
> Here maybe we would benefit by some support (macros, whatever) that
> permits us to specify in a compact way what to do around f() should
> it become blocking.
>
> On the other hand, maybe the instances of code as the one above
> are so rare that there is hardly any need for that.
>
Correct me if I'm wrong but I suspect you're thinking of cases such
as:
RT_UNLOCK(rt); /* XXX workaround LOR */
gwrt = rtalloc1(gate, 1, 0);
RT_LOCK(rt);
in the routing/networking code. A quick, and by no means exhaustive,
check of CURRENT with cscope and Emacs looking for these turned up 3.
It may still be something to look at, but perhaps mroe from a point of
view of cleaning up our APIs to not do this kind of jiggery pokery,
rather than inventing a new locking paradigm, which is fraught with
peril.
This isn't exhaustive though, if others can show this kind of thing
being done a lot, or becoming a idiom in our code, then there is more
cause for concern.
Just my 2 yen :-)
Later,
George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2pssdjoob.wl%gnn>