Re: [gtk-list] Re: Making gtk thread-safe

[Rob Browning <rlb cs utexas edu>]

Elliot Lee <sopwith@redhat.com> writes:

> I don't know if Xlib has its own global mutex - if it does then obviously
> a global gtk/gdk mutex would be the best thing.  But if Xlib can be truly
> called reentrantly, that means instead of having one thread with an X
> request in progress and other threads blocking until that request
> completes, we could have multiple threads awaiting responses from the X
> server or just doing general processing. 

The only threads stuuf I've read about is the info in "Programmers
Supplement for Release 6".  It only mentions Xt threading issues,
including XtToolkitThreadInitialize, XtAppLock, and XtAppLock.  The
lock and unlock functions aren't necessary when using Xt functions
which take an app context, widget, or display as a parameter (most of
them) because they lock the relevant structures implicitly.  So
XtAppLock and XtAppUnlock are mostly for making sequences of calls
atomic.  The book does have some guidelines for writing multithreaded
widgets that might be useful.

> We don't even need to exclude other threads from reading data
> structures, just writing to them needs to be locked. Perhaps a
> counter that lets us know how many threads are reading a resource,
> and a mutex for locking access (to be used by threads which need to
> write to a resource).

This is a fairly straightforward readers-writer problem.  I can
provide a nice implementation of this that just relies on POSIX
threads if it would be useful.  The functions are (something like):

  rw_reader_enter(rw_struct);
  rw_reader_exit(rw_struct);
  rw_writer_enter(rw_struct);
  rw_writer_exit(rw_struct);

The code ensures that any number of readers can be reading unless a
writer is writing, and there can only be one writer writing.

> Can the increment and decrement operators be assumed to be atomic?

No.  You always need to use a mutex -- even if we know it's atomic on
x86's under Linux with gcc, that doesn't mean it will be on a
multiprocessor Alpha running the HURD :>

> What's the best way to suspend a thread until the read counter == n?

Careful use of semaphores/mutexes.  Note that getting the
implementation right and avoiding starvation given varying
implementations of POSIX threads (the standard is not as restrictive
as you might like) is a little tricky, but I've done it a couple of
times, and I'd be glad to donate code (or whatever advice I can) if
desired.

<RANDOM SEMI-RELATED ASIDE>

Note that some people (including me :<) use static initializers to
make sure that a given library is initialized at program startup
(without the user having to explicitly initialize it).  The stdio lib
is such an example.  I realized (after some aggravation) that you have
to be really careful if you want to get this right.  There's nothing
in C/C++ to guarantee that the lib will be initalized before the
user's other static initializers fire.  If they use your library in
these initalizers, then you're dead.  The trick is to realize that C
does guarantee that statics will be *zeroed* if not initialized before
any static initializers fire.  Using that and some carefully placed
code, you can make sure everything works safely.

</RANDOM SEMI-RELATED ASIDE>

Possibly a better answer is to just insist that the user manually
initialize the lib before using it.

> Most multithreaded windowing apps currently available may dedicate one
> thread, but we don't want to limit people to this approach! :-) I think
> the best solution depends on knowing how well Xlib implements reentrancy.

Sounds like a plan.

-- 
Rob