[PATCH 2/4] X event queue mutex
Keith Packard
keithp at keithp.com
Thu Oct 2 15:11:36 PDT 2008
On Thu, 2008-10-02 at 18:58 -0300, Tiago Vignatti wrote:
> Keith Packard escreveu:
> > The input queue is written so that each user modifies only one of the
> > two pointers (head and tail). There shouldn't be any need to have a
> > mutex which protects both of these values together, and doing so
> > prevents mouse motion while the server is processing events.
>
> Yeah, but the input thread can change the tail pointer while the main
> thread is reading that, doing dirty things.
That won't be a problem on any SMP machine where writes from one CPU are
visible to the other CPU. The key is to have each thread writing only
one of the two values, and we have that already.
> And doing mutex will _not_ prevent the cursor update on the screen while
> the server is processing the events. The update is done before the
> routines of event enqueue, so no mutex there.
The input thread will block before enqueuing while the X server pulls
events out of the queue, causing it to stop reading events and updating
the cursor.
The X server also reads the input queue pointers from DIX before calling
into ProcessInputEvents, so you aren't safe against memory write races
(where writes to one location are visible across CPUs before writes to
another location).
So, we either need to fix the users of checkForInput along with all
users of miEventQueue, or we need to assert that we're running on a
sensible CPU that doesn't require a mutex to make memory changes visible
across processors, in which case we don't need any mutex at all.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081002/5fd12963/attachment.pgp>
More information about the xorg
mailing list