On Oct 23, 2008, at 16:05, Tiago Vignatti wrote:
Hey Jeremy, I'm going well. Thanks my friend. Jeremy Huddleston escreveu:I hope things are going well for you. I've recently hit an issue using locks in miEq. We're doing it the same way in mieq.c as your proposal (patch 2/4) and this causes us to hit a deadlock when the enqueueing thread is waiting for the lock to push an event and the dequeuing thread (the server thread) is processing an event that requires a message to be sent to the enqueueing thread.I posted another version of that patch that doesn't requires a lock in mieqProcessInputEvents().
Hmm... I must've missed that version... I thought I was looking at the Oct 1 one, but maybe I misclicked... sorry
We just need to guarantee order of events enqueued (to protect writes to the tail pointer in mieqEnqueue) and don't need to serialize dequeuing events. So no locks in the server thread is needed. (well, this is the theory of the X server with Xorg DDX and the input thread craziness. Maybe your problem is a bit different from mine)
I think by not locking, we open ourselves up to clobber because we reference the event on the queue after we pop the event off the event queue:
server thread: e = miEventQueue.events[miEventQueue.head]; miEventQueue.head = (miEventQueue.head + 1) % QUEUE_SIZE;-- context switch to input thread with a 1-open-slot event queue (miEventQueue.head = miEventQueue.head - 1) -- miEventQueue.events[miEventQueue.tail] gets set, but this is what 'e' is.
-- context switch to server thread -- e was just clobbered by the input thread -----I think you're right, actually, that we don't need to actually lock here. We just need to copy the data locally then pop the queue. If we keep the data in the queue and point to it, then we need to either lock (bad IMO), pop on return (possibly a good solution), or cache it locally (what I did in the patch I sent a few hours ago).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
