Philip Brown wrote:
If my understanding is correct, the "lightweight lock" basically amounts to a user-level spin lock. If a process detects that some other process is holding the spin lock, it goes into the kernel to get the heavyweight lock. Obviously having a process sit on a spin lock on a UP system is a bad idea.I've been reading http://dri.sourceforge.net/doc/hardware_locking_low_level.htmland the code, obviously... so I've seen references to the "lightweight" lock. ButI have yet to figure out why there is one. The url document mentions that one supposedly exists, and that "the lightweight lock will not be designed to be shared between GLXContexts" and that "The lightweight lock will be stored in a user-space shared memory segment that is available to all locking entities." But it doesnt seem to spell out exactly what the lightweight lock should be used for, or what the kernel's role in it should be. Can I basically just ignore the "lightweight lock" at kernel level, and let the userspace code sort itself out?
Linux has a built-in mechanism like this (futex?) that didn't exist when the DRM was first conceived. It's to bad we can't modify the DRI drivers to just wrap that interface, and use that on Linux and the "legacy" implementation on other OSes.
I believe that's the intention. The lightweight lock is just a spin lock, and the heavyweight lock uses whatever kernel mutex mechanism is available. I'll have to look at it, but drm_low_level.html should probably be updated to reflect this. A few more details in the documentation can't hurt. :)Also, as far as the heavyweight lock goes... It has been described as, "The hardware lock is obtained whenever the hardware is touched, and holding the lock implies that no other entity in the system will touch the hardware. " [http://dri.sourceforge.net/doc/drm_low_level.html] That being the case, I'm thinking of just having the heart of ioctl(DRM_IOCTL_LOCK) be a straight kernel mutex, since solaris supposedly handles mutex queueing fairly well, rather than implementating a whole separate queue mechanism. Any comments on this?
I also hope you're keeping good notes. A "how I ported the DRM to Solaris" document would make an awesome addition to the DRI documentation. :)
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
