Browse Prior Art Database

Multiple-Threaded Graphics Applications and X-Windows Motif

IP.com Disclosure Number: IPCOM000113328D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 95K

Publishing Venue

IBM

Related People

Baker, RJ: AUTHOR [+3]

Abstract

X-Windows is the graphics environment found on most UNIX workstations. Current releases of the X-Windows system (i.e., X11.4 and X11.5) do not support multiple threads of execution in the calling application, unless all calls are made from one thread only. In fact, X-Windows is unaware of threads, so calls can be made from any thread and X-Windows will only know what process the call was made from. X-Windows will therefore fail if calls are made from more than one thread at the same time; which is possible when using premptive multi-tasking.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

Multiple-Threaded Graphics Applications and X-Windows Motif

      X-Windows is the graphics environment found on most UNIX
workstations.  Current releases of the X-Windows system (i.e., X11.4
and X11.5) do not support multiple threads of execution in the
calling application, unless all calls are made from one thread only.
In fact, X-Windows is unaware of threads, so calls can be made from
any thread and X-Windows will only know what process the call was
made from.  X-Windows will therefore fail if calls are made from more
than one thread at the same time; which is possible when using
premptive multi-tasking.

      A software program may use multiple threads in its
applications, and these applications issue X-Windows calls from
multiple threads.

The problems to be solved, are to ensure that:

o   Only one thread at a time explicitly processes X-Windows calls.

o   The unaware thread is prevented from processing X-Windows calls
    at these times.

      An unaware thread, is one which automatically performs graphics
tasks without explicit requests from the programmer, usually to
provide general services.  Importantly, our solution, described
below, can be implemented by simply adding some initialisation code
to a 'main' unaware thread; and then adding extra calls to code
running on subsequent threads.  This allows implementation with
minimal restructuring.

      Other schemes for locking X-Windows calls on each thread, or
passing messages between  threads so that all X-Windows calls were
made by one thread,  have  the  disadvantage  that the main thread
code would have to suffer major change, either to add lock calls
around  graphics functions,  or  to  understand the type of graphics
calls the other threads may wish to use.

      Another advantage is that X calls can be grouped, with only one
set overhead for the group.  By comparison if all X calls are
performed on one thread then there is a communications overhead
associated with each call.

      All group semaphore settings are assumed atomic, and instantly
executed.  If they are not then controlling semaphores are required
to ensure that access writes to the group of FIFOs is atomic, and
that all final clears have occured before a new request is started.

      In our software program atomicity was sufficient, FIFO access
was inherently serialised (only one FIFO), but instantaneous clearing
was not guaranteed, so one controlling semaphore was required.

      Firstly, a mechanism has to be used for communicating between
the various threads.  Key to this solution is the use of a FIFO pipe
to pass messages to the unaware thread.  Using an XtAppAddInputs call
in the initialisation code for the unaware thread, removes the need
to add code to this unaware thread to monitor the FIFO.  Using the
XtAppAddInputs call X-Windows will monitor the FIFO and automatically
hand on any requests to this thread.  Thus the only addition to the
unaw...