Conference bulova::decw_jan-89_to_nov-90

> My question is whether DECwindows under Ultrix (4.0 or greater) is thread safe? 
> Can a DECwindows application linked with our library safely be interrupted by
> one or multiple threads of execution?

No, neither the Intrinsics, XUI, nor Motif are tread re-entrant.  Probably
won't be for a while either.  We keep bringing this issue up at MIT and
OSF every chance we get, but we seem to be the only vendor that cares.

Leo

I agree with Leo.  However, that does not mean that you are SOOL.  If you
Mutex around all DECwindows/X calls and assign a thread for each application
context and an application context for each application shell, you can do
a fairly effective job of multi-threading a DECwindows application.  It took
us awhile to shake out the change to multi-threading.  It should be easier if
you do it from day 1.

Dick

a) What they said.

b) Don't just "lock a mutex" around DECwindows or Xlib calls; use the CMA
   "global lock".  That's cma_lock_global and cma_unlock_global.  It's a special
   kind of mutex that allows the same thread to relock it without hanging; so
   you can lock it every time you call (even if the call is from an Xtoolkit
   callback routine where the mutex may already be locked).

c) The big problem is X event management.  The Xt event loop will block the
   whole process until the next CMA timeslice (or until an event comes in).
   You probably ought to write your own loop; check if there's an Xt event,
   dispatch it if so, otherwise do a cma_delay for a short time to let other
   threads run (or at least a cma_yield).

.1: Leo, I'm shocked to hear that nobody else has yet shown any interest in
threaded DECwindows.  I've been beating on this for years, and I thought I'd
heard something about how Athena was "looking at it".  Several weeks ago we
voted to send POSIX 1003.4a (pthreads) to ballot.  It'll still be a while till
it's a real formal standard, but I can absolutely guarantee that DEC ain't the
only ones already working on pthread implementations.  Especially considering
that OSF/1 has threads and Motif, if the people in control of the intrinsics
really haven't sensed any need to get their heads out of 

   I'd read (lordy, I can't remember where) something about MIT considering
thread-reentrant Xtk/Xlib designs for the future.  I think it was
electronically, in which case it was probably either in
comp.windows.x or the RDVAX::X conference, but it might have been a paper
somewhere.

   Actually the Xtk design I recall was something more around each widget
being a thread, not just having the things being thread-reentrant.

						-mjg

Dave,

Is it true that XtNextEvent will block the whole process?  We hadn't gotten
that far though we did have some ideas (similar to but no the same as your
cma_delay suggestion) to get around it.

Dick

RE: .5

Yes, it's true that it blocks the whole process.

--PSW

    However, you don't HAVE to call XtNextEvent.  You can use XtPending and
    XtProcessEvent instead.
    
    Leo

.7

Yep, that's what we do anyway.  I was just making sure I understood so that I
could avoid stupid changes that might break something 8^{).

Dick

We're currently working from a pretty old manual, which doesn't contain
cma_lock_global.  Is this a single "special" Mutex or a special class of Mutex?
If you lock it multiple times, is this a nested lock or will a single unlock
be sufficient?

I am still not convinced that you want to lock access to "global" things when
what you really mean is "don't do DECwindows".  There are other things that
are kind of global that should have their own Mutex as well.

Dick

Actually, if you have any further questions, you should take up the discussion
in our CMA conference, CLT::CMA.  This is getting a bit off the topic of
"DECwindows".  By the way, the latest CMA architecture "manual" is available in
CLT::CLT$LIBRARY:[CMA.SPECS]CMA.PS.  It conforms to what we currently expect to
make available with CMA BL4 (we've put the code outside, and with the way the
weather is going, we expect it to freeze any day now :-) ).

Anyway, cma_lock_global and cma_unlock_global take no arguments, and do not
return any values.  They operate on a single "friendly" mutex (which allows
relocking within a single thread to accomodate things like callbacks and
nested subsystems which require locking).

We freely admit (advertise) that the CMA global lock is a HACK; it's the only
reliable way to work around subsystems which aren't thread reentrant.  A
facility CAN'T use its own mutex; because if another facility uses a different
mutex to protect entry to the same non-reentrant subsystem, then neither has
any real protection.  There must be only ONE mutex to protect ALL non-reentrant
subsystems, because in general nobody can guarantee for all time what the
dependency tree looks like.  For the same reason, it must be a "friendly"
(relockable) mutex.  If it's not "friendly", and you lock it to call one
subsystem, which itself must call another subsystem, you'd get a deadlock.  If
there are multiple locks, then you must know and lock ALL subsystems which may
be invoked by any call you make.  If any subsystem adds a call to a new 
subsystem, then all callers must change to make the appropriate locks.

None of this would be a problem if all facilities were thread reentrant, or if
we could ensure that any facility that gets changed from now on would be MADE
thread reentrant.  But obviously neither of those is going to be true.  We
came to the conclusion that CMA must provide one, and only one, global friendly
mutex to provide interlocking for ALL nonreentrant libraries.

We implemented "friendliness" as an attribute of standard mutexes, so in theory
you can create additional friendly mutexes; however I'm not at all convinced
that there's any real use for more than one friendly mutex in a system, and I
strongly recommend that nobody start creating them.  Using anything other than
the CMA global mutex to protect a non-reentrant subsystem is unsafe.  Using a
friendly mutex just to make it "easier" to code (not having to worry about
whether a function that locks a structure might call another function that needs
to lock the structure) is probably just complicating maintenance of the system,
and hurting performance (a friendly mutex is significantly more expensive than
a default "fast" mutex).

	/dave

I am going to take this conversation over to CLT::CMA.  I don't think that .10
answered all of the questions that I raised.

Dick

From the annual X Consortium Advisory Committee meeting Sept 18:

31. Release 5 Progress

	<stuff removed>

        Jake VanNoy:  Will there be support for POSIX threads in Xlib or Xt?

        Bob:  No, although we've given some thought to Cthreads.

        Jake VanNoy:  Is anyone else interested in having Pthreads?  [not many]

I tried...

re: .4
>   I'd read (lordy, I can't remember where) something about MIT considering
>thread-reentrant Xtk/Xlib designs for the future.  I think it was
>electronically, in which case it was probably either in
>comp.windows.x or the RDVAX::X conference, but it might have been a paper
>somewhere.

This may be what you saw:


19. Multithreaded Server

    A.  Status
        i.  Some progress has been made in the design, but it has been
            hindered by the impact of staff reductions on the R5 schedule.

        ii. Bob doesn't expect that they'll have time to get back to it
            until December.  There isn't very much written down right now.

        iii. But, Bob and Keith believe they understand the problem and have
            some good ideas on how to fix it.

    B.  Companies that are interested in visiting and discussing the design
        in depth are welcome.

    C.  This work is independent of R5.

Well, thanks for the update, Jake... however disappointing it may be :-)

	/dave

I tried writing my own main loop, but there appears to be a problem with
XtPending/XtNextEvent. Seems that everything works ok when the application does
not have focus and XtPending returns with no indication of an event. When I give
focus to the application, the XtPending returns, but I never get back out of 
XtNextEvent. Only thing that I can think of is that the blinking cursors are 
getting in the way somehow. Am I confused - I thought this was the way that the
toolkit main loop used to work...

  while (not_done) {
   if (XtPending(dpy)) {
    XtNextEvent(dpy,&event);
    XtDispatchEvent(dpy,&event);
   }
   else
    /* do other interesting things */
  }

Use XtProcessEvent instead of the pair of XtNextEvent and XtDispatchEvent.
XtProcessEvent handles one XtEvent (XEvent, timeout or alternative input)
and returns.  XtNextEvent handles timeouts and alternative inputs without
returning.  XtDispatchEvent only works on XEvents.

Dick