Re: [AD] proposal: remove XLOCK/XUNLOCK

[Chris <chris.kcat@xxxxxxxxxx>]

On Sunday 23 April 2006 13:32, Elias Pschernig wrote:
> > However, just like with bitmap/screen locking, it'd be useful to do it
> > manually just once for a group of commands instead of letting each
> > command lock itself.
>
> Not sure. A mutex should be a pretty lightweight operation.

I think it depends on how many threads are actively trying for the mutex. If 
it's just one thread, or two threads where the second only does an erant 
command here or there, it should be relatively lightweight. However, if you 
have two or more threads constantly trying to grab a lock, it'll all slow 
down as the threads just start waiting for each other.

Thread 1 grabs a lock and runs function 1
Thread 2 wants a lock, waits for Thread 1
Thread 1 releases lock
Thread 2 grabs a lock and runs alt_function 1
Thread 1 wants a lock, waits for Thread 2
Thread 2 releases lock
Thread 1 grabs a lock and runs function 2
Thread 2 wants a lock, waits for Thread 1
Thread 1 releases lock
Thread 2 grabs a lock and runs alt_function 2
Thread 2 releases lock
...

Instead of:

Thread 1 grabs a lock, exectutes function 1
Thread 2 wants a lock, waits for Thread 1
Thread 1 executes function 2
Thread 1 releases lock
Thread 2 grabs lock, executes alt_function 1
Thread 2 executes alt_function 2
Thread 2 releases lock
...

And it just gets worse the more functions and threads want the lock.

> > Plus, can we gaurantee X will always lock for us? Is it in any
> > official documentation? Can we assume it'll always be this way even for
> > other implementations (eg. XGL or AIGLX)?
>
> Yes, true. If XLockDisplay actually is needed, then we can't remove
> XLOCK/XUNLOCK. But to me it looks like "XLockDisplay" or something else
> is always called by X11, and in case XInitThreads was not called, it
> does the check for "async reply", otherwise it uses a pthreads mutex.

IIRC, we originally were using XLockDisplay/XUnlockDisplay, but you suggested 
using pthread mutexes since it seemed to do the same thing and was probably 
more lightweight. I still say we should be using X's lock/unlock functions 
instead of pthread's mutexes since you can't really know if X may have its 
own threads trying to run functions on our display, in which case we'd need 
to use X's locking mechanisms or risk it interupting and causing an async 
error.