cvs commit: src/share/man/man4 ipfirewall.4 src/share/man/man9 pfil.9 src/sys/alpha/conf GENERIC src/sys/amd64/conf GENERIC src/sys/conf NOTES files options src/sys/i386/conf GENERIC src/sys/ia64/conf GENERIC SKI src/sys/modules/bridge Makefile ...

[John Baldwin]

On Friday 27 August 2004 04:52 pm, Max Laier wrote:
> Take a look at how sx(9) is implemented. What is there in pfil now is not
> very different. Long story short sx(9) has even more overhead and has
> starvation problems.

It also has WITNESS checking whereas home rolled locks don't and can more 
easily lead to buggy code with deadlocks.  sx(9) is just a mutex with a 
couple of cv's.  Note that cv's have no additional overhead compared to 
msleep, in fact since their wait functions are more specific they may be 
slightly quicker for the cases that you aren't doing a timeout or a signal 
catch.

> > The strategy currently in place is more akin to something that would
> > be used in a device driver where you have two "halves" and one will
> > sleep.  In none of the code wrapped by PFIL_WLOCK is there anything
> > that will make the system wait.
>
> You cannot sleep with PFIL_WLOCK held. It's a plain mutex lock!
>
> > The use of sx(9) should be a no-brainer.
>
> Yes, but it will reduce performance and introduce stravation problems. Once
> we have a better sx(9) implementation I am all for switching over. Right
> now it does not work.

What starvation problems?  A shared unlock gives precedence to waiting writers 
and an exclusive unlock gives precedence to waiting readers.  This is very 
similar to rwlocks in Solaris with the exception that the sx code currently 
doesn't take priority into account when making this decision.

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