The DRI drawable spinlock

Thomas Hellstrom unichrome at
Fri Apr 22 01:44:44 PDT 2005


Does anybody have a clear understanding of the drawable spinlock?

 From my reading of code in the X server and dri_utilities.c it is ment 
to be used to stop anyone but the context holding the lock to touch the 
dri drawables in a way that would change their timestamp.

The X server has a very inefficient way of checking whether a client 
died while holding the drawable spinlock. It waits for 10 seconds and 
then grabs it by force.

Also the usage is dri_util.c is beyond my understanding. Basically, to 
lock and validate drawable info, the following happens:


while drawable_stamps_mismatch {
    //In dri_util.c
   //In driver.

Basically no driver seems to be using it for anything, except possibly 
the gamma driver, which I figure is outdated anyway?

I have found some use for it in XvMC clients: To run the scaling engine 
to render to a drawable without holding the heavyweight lock for 
prolonged periods, but I strongly dislike the idea of freezing the X 
server for 10 secs if the XvMC client accidently dies.

Proposed changes:

1). Could we replace the locking value (which now seems to be 1) with 
the context number | _DRM_LOCK_HELD. In this way the drm can detect when 
the drawable lock is held by a killed client and release it.

2). Could we replace the drawable_spinlock with a futex-like lock 
similar to what's used in the via drm to reserve certain chip functions. 
The purpose would be to sched_yield() if the lock is contended, with an 
immediate wakeup when the lock is released. This would not be backwards 
binary compatible with other drivers, but it seems no up-to-date drivers 
is using this lock anyway.


More information about the xorg mailing list