The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock.
I wonder if we didn't throw out the baby with the bathwater when we reorganized the kernel side DMA buffer management.
To be more specific, we do call the kernel unlock routine when there is lock contention, but it's not clear which compile time code paths are used by Linux in the supporting DRM code responsible for waking up the contending thread. Check out DRM(unlock) in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h
This is precisely where Linux specific support for "wake-up the next waiting thread" should reside. I see calls to wake_up_interruptible(&dev->lock.lock_queue), but they are ifdef'ed by __HAVE_KERNEL_CTX_SWITCH.
I'm not certain which compile time paths we're using in this code these days...but somebody is waking up the clients that are waiting for the lock and this is precisely where it should be happening. When it does happen here, this behavior would appear to be almost identical to the behavior of the futex you describe.
--
/\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
