source: trunk/src/gcc/libobjc/THREADS@ 1005

This file describes in little detail the modifications to the
Objective-C runtime needed to make it thread safe. 

First off, kudos to Galen Hunt who is the author of this great work.

If you have an comments or just want to know where to
send me money to express your undying gratitude for threading the
Objective-C runtime you can reach Galen at:

        [email protected]

Any questions, comments, bug reports, etc. should send email either to the
GCC bug account or to:

        Scott Christley <[email protected]>

* Sarray Threading:

The most critical component of the Objective-C runtime is the sparse array
structure (sarray).  Sarrays store object selectors and implementations.  
Following in the tradition of the Objective-C runtime, my threading
support assumes that fast message dispatching is far more important
than *ANY* and *ALL* other operations.  The message dispatching thus
uses *NO* locks on any kind.  In fact, if you look in sarray.h, you
will notice that the message dispatching has not been modified.
Instead, I have modified the sarray management functions so that all
updates to the sarray data structure can be made in parallel will
message dispatching.  

To support concurrent message dispatching, no dynamically allocated
sarray data structures are freed while more than one thread is
operational.  Sarray data structures that are no longer in use are
kept in a linked list of garbage and are released whenever the program
is operating with a single thread.  The programmer can also flush the 
garbage list by calling sarray_remove_garbage when the programmer can
ensure that no message dispatching is taking place concurrently.  The
amount of un-reclaimed sarray garbage should normally be extremely
small in a real program as sarray structures are freed only when using
the "poseAs" functionality and early in program initialization, which
normally occurs while the program is single threaded.

******************************************************************************
* Static Variables:

The following variables are either statically or globally defined. This list 
does not include variables which are internal to implementation dependent 
versions of thread-*.c.

The following threading designations are used:
        SAFE   : Implicitly thread safe.
        SINGLE : Must only be used in single thread mode.
        MUTEX  : Protected by single global mutex objc_runtime_mutex.
        UNUSED : Not used in the runtime.

Variable Name:                  Usage:  Defined:        Also used in:
===========================     ======  ============    =====================
__objc_class_hash               MUTEX   class.c
__objc_class_links_resolved     UNUSED  class.c         runtime.h
__objc_class_number             MUTEX   class.c
__objc_dangling_categories      UNUSED  init.c
__objc_module_list              MUTEX   init.c
__objc_selector_array           MUTEX   selector.c
__objc_selector_hash            MUTEX   selector.c
__objc_selector_max_index       MUTEX   selector.c      sendmsg.c runtime.h
__objc_selector_names           MUTEX   selector.c
__objc_thread_exit_status       SAFE    thread.c
__objc_uninstalled_dtable       MUTEX   sendmsg.c       selector.c
_objc_load_callback             SAFE    init.c          objc-api.h
_objc_lookup_class              SAFE    class.c         objc-api.h
_objc_object_alloc              SINGLE  objects.c       objc-api.h
_objc_object_copy               SINGLE  objects.c       objc-api.h
_objc_object_dispose            SINGLE  objects.c       objc-api.h
frwd_sel                        SAFE2   sendmsg.c
idxsize                         MUTEX   sarray.c        sendmsg.c sarray.h
initialize_sel                  SAFE2   sendmsg.c
narrays                         MUTEX   sarray.c        sendmsg.c sarray.h
nbuckets                        MUTEX   sarray.c        sendmsg.c sarray.h
nindices                        MUTEX   sarray.c        sarray.h
previous_constructors           SAFE1   init.c
proto_class                     SAFE1   init.c
unclaimed_categories            MUTEX   init.c
unclaimed_proto_list            MUTEX   init.c
uninitialized_statics           MUTEX   init.c

Notes:
1) Initialized once in unithread mode.
2) Initialized value will always be same, guaranteed by lock on selector 
   hash table.


******************************************************************************
* Frontend/Backend design:

The design of the Objective-C runtime thread and mutex functions utilizes a
frontend/backend implementation.

The frontend, as characterized by the files thr.h and thr.c, is a set
of platform independent structures and functions which represent the
user interface.  Objective-C programs should use these structures and
functions for their thread and mutex work if they wish to maintain a
high degree of portability across platforms.

The backend is composed of a file with the necessary code to map the ObjC
thread and mutex to a platform specific implementation.  For example, the
file thr-solaris.c contains the implementation for Solaris.

If you are compiling libobjc as part of GCC, the thr-objc.c backend is
always used; this backend uses GCC's gthread code.  The thread system
is automatically configured when GCC is configured.  Important: make
sure you configure GCC using `--enable-threads' if you want threads !
  
If you want to compile libobjc standalone, then you would need to
modify the configure.in and makefiles for it; and you need to pick an
appropriate backend file for the target platform; you make this choice
by assigning the OBJC_THREAD_FILE make variable to the basename of the
backend file.  For example, OBJC_THREAD_FILE=thr-posix would indicate
that the generic posix backend file, thr-posix.c, should be compiled