[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Chris wrote:
Peter Wang wrote:
Hmm, is this due to a deficiency in the current implementation, or is
there nothing further Allegro can do?
It seems to be a deficiency in Xlib's locking system. One would think
that when you unlock a display mutex, Xlib would automatically switch
to another thread if it was waiting on a lock.. this appears to not be
the case though.
I think automatically switching to another thread would really hurt
performance if all mutexes worked that way (and this is surely the
domain of the thread system and not Xlib).
So what happens is the lock is released, then quickly locked again by
the main thread leaving little time for input and such to be gotten.
About the only thing I can think of for Allegro to do is yield
whenever XUNLOCK is called, but that would play havoc with the rest of
the program.
Unfortunately, I don't think you can set thread priorities in
LinuxThreads. Not sure about NPTL. That would be something to try.
Maybe we could try something using condition variables?
XLOCK():
pthread_mutex_lock(&m);
while (num == 0)
pthread_cond_wait(&cv, &m);
num--;
pthread_mutex_unlock(&m);
XUNLOCK():
pthread_mutex_lock(&m);
num++;
pthread_cond_broadcast(&cv, &m);
pthread_mutex_unlock(&m);
... er, which just implements a counting semaphore. Since num will be
initialised to 1, it's nothing more than a mutex! But I *think* the
pthread_cond_broadcast() would wake up a waiting thread.
pthreads has semaphores, too, which might be worth looking into.
Peter