Quoting Linus Torvalds ([EMAIL PROTECTED]): > > On Thu, 29 May 2003, Keith Whitwell wrote: > > > > The lock doesn't seem to be 'fair' like that - in practise it isn't transfered > > to the waiting process (unless you do a sched_yield() after unlocking). > > Indeed. If you want fairness, you need to code for it explicitly. It's not > hard per se, but it does slow down locking, sometimes noticeably. This is > not likely to be a huge problem for DRI, but it comes up in other > circumstances (ie in-kernel spinlocks don't even try to be fair, it's just > too expensive and if you get the kind of contention that you care you must > do something else altogether). > > The DRI locking really should be revisited at some point. It could > probably be done more cleverly, and without these problems.
In the kernel part of Fusion (our IPC API) I'm currently calling yield() after unlocking a "long-time" lock. Maybe you have some hints before I'm working on that issue. BTW, you might want to look at Fusion when you have time (see our web cvs). We had to do an IPC API from scratch, because SysV IPC was not sufficient enough to reach the current level of stability and speed. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
