Special schedulers, one CPU only kernel, one only userland

[John Baldwin]

On Tuesday 16 August 2005 10:13 pm, gnn at freebsd.org wrote:
> 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 :-)

Agreed.  I'd rather that we fix our APIs and try to organize the workflow to 
minimize the number of times that a lock has to be dropped and then 
reacquired.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org