Multithread communication and data sharing libraries for TCL 
Author Message
 Multithread communication and data sharing libraries for TCL

I was planning on waiting till I had a full scale implementation and
great demos, but since there seems to be some interest in this, I
thought I'd get a rough cut of my proposal out onto the net.

Inter-Thread communications and data sharing libraries for TCL.

The current implementation of Tcl is not designed to be thread-safe,
which makes communication and data sharing among Tcl interpreters within
a single process problematic.

The need exists for a thread safe means of sharing data and
synchronization among Tcl interpreters within a single process.

Any solution should naturally extend Tcl with the mechanisms provided by
Tcl for linking C with Tcl.  There should be no changes to the
implementation of Tcl itself.

An immediate and natural use for this is GUI design.  A general enough
solution would allow a Tcl interpreter in one thread to be dedicated to
controlling a GUI.  Other threads could communicate with this GUI
dedicated thread.  Not only does this increase the responsiveness of the
GUI, but it allows one to quickly and efficiently add a GUI to an
application that is not designed to work with Xt, on which Tk is based.
An application may want to maintain it's own main control loop, rather
than relinquishing control to the X event handling loop.
Inter-thread communication would make it easy.


Why Tk "send" is not sufficient for inter-thread communication:

Tk does provide an excellent means of communication among Tcl
interpreters in separate processes, and even communication among
different interpreters within a single process.
However, each process that wishes to use send must be initialized to use Tk.
Tk will allow an interpreter to "send" to itself.  But, the internal
implementation of Tk "send" checks to see if a send is to the current
interpreter, and executes the send globally, rather than using the X
server to "send", as it normally does.


A proposed solution:

This is a skeleton outline of the work I have already done in
implementing a general solution to this problem.
I want to get some feedback before I go any further.
This outline is not intended to cover implementation.
It primarily covers the API's and the usefulness of important features.

I am not going to cover initialization routines right now.
I don't find them important in the overall design, and I am looking
for feedback on just that, overall design of the API's.

The solution I am proposing can be broken down into two components.
The first, a shared data space, facilitates thread safe data sharing
among interpreters.  
The second is a set of synchronization routines, that allow threads to
signal one another.
Synchronizing data sharing between a Tcl thread dedicated to handling
a GUI and a data processing thread is an excellent example of how both
of these features can be used.

A Shared Data Space (SDS):

sdsSet <key> <value>
sdsGet <key>
sdsDel <key>

The SDS is a data repository to which any Tcl Interpreter initialized to
use the SDS calls has access.  This allows Tcl Interpreters to share
data, even if the interpreters are in different threads.
As well, there is a C API, which allows any thread in a process to share
data with Tcl Interpreters and any other thread.

sdsSet sets an entry in the SDS indexed with <key> to <value>.
It returns the value to which <key> is set.
If a value already exists for <key>, the old value will be overwritten.

sdsGet returns the value in the SDS, indexed by <key>.

sdsDel deletes the value in the SDS indexed by <key>.
It returns the value of the key that was just deleted.
If no value exists in the SDS for <key> the NULL string is returned.

My current SDS implementation does allow multiple SDS's to exist
within a process.  But, a Tcl interpreter can only use one SDS once it
is intialized.  Other interpreters who wish to share data must be
initialized with the same SDS.

There are C calls to initialize and destroy an SDS and to initialize
an interpreter with an SDS.

Synchronization facilities:

sigSignal <interp> <signal>
        [-priority <SIG_PRI_NORMAL | SIG_PRI_HIGH>]
        [{ <pre_signal_code> }]

sigWait handle (x) { <signal_x_handling_code> }
        [handle (y) { <signal_y_handling_code>} ...]
        [handle_default { <default_signal_handling_code> }]

The synchronization facilities are initialized with C procedures.  It is
then that interpreters are named with strings.  Tcl
interpreters can than signal one another by name.

Tcl signals can be initialized before the synchronization code is run.
Application specific signals can be created and used for application
specific needs.
There are no default Tcl signals.

sigSignal will signal another interpreter (or C thread) which is
intialized with the name <interp> with <signal>, a Tcl signal.

Signals are queued when they are received by an interpreter.  So,
there is no need to worry about overwriting signals.
Also, signals are not lost if the receiving interpreter is not waiting
for a signal before a signal is sent.

sigSignal takes a code block, { <pre_signal_code> }, which will be
executed before a signal is sent.
This is useful for setting shared data that the receiving interpreter
will be reading once the signal is received.

-priority allows you to set the priority which the signal will be
sent.  SIG_PRI_NORMAL is normal priority, which means that the signal
be placed last on the receiving interpreters queue.
SIG_PRI_HIGH is high priority, which means that the signal being sent
will be placed first on the receiving interpreter's queue, and will be
handled by the receiving interpreter before any signals that were on
the queue before the signal is sent.
The default is SIG_PRI_NORMAL.

-wait will force sigSignal to wait for the signal to be handled by the
receiving interpreter.
Normally, the signal is placed on the receiving interpreter's
receiving queue, and the sending interpreter does not care if the
signal is handled or not.
-wait will force lock-step synchronization.

sigWait lets you set up handlers for different signals.
It will wait for a signal if none are on the signal queue, or it will
handle the next signal on the signal queue if there are signals on it
already.  The handlers are useful for getting data from the SDS, or
doing clean up activities.

You can specify a default handler (handle_default) whose associated
code block will be executed if sigWait receives a signal that has no
handler specified for it.
Without the default handler, an error will be raised if a received
signal has no handler.


C API notes for synchronization routines:

I've also implemented a similar C API so that any thread can
communicate with Tcl interpreters in other threads and any other
thread for that matter.  Again, great for adding GUI's to

My current implementation of the C API for synchronization routines
depends on DCE exception handling.  I had written these Tcl extensions
to work with packages that my company sells that use exception
handling.  I plan to write a version of the C API
that does not use DCE exception handling.

The C API for synchronization are actual constructs, not procedures.
This allows you to write signal handling code and pre-signal sending
code withing the contructs.  You do not have to create new procedures
to handle signals and handle data.  It can all be done in place.
(More about that later.)


An example: To come soon.

I do have a working demo right now, but I still want to clean it up.
My current implementation is based on DCE threads.
This is easily ported to any other threads package.

Thu, 08 Feb 1996 12:21:31 GMT  
 Multithread communication and data sharing libraries for TCL

   This is a skeleton outline of the work I have already done in
   implementing a general solution to this problem.
   I want to get some feedback before I go any further.
   This outline is not intended to cover implementation.
   It primarily covers the API's and the usefulness of important features.

Rather than providing a low level api consisting of shared variables
and condition variables, why not do something higher level, like
Linda?  One advantage of that is (purportedly) easier programming.
Another is that you can make arrays behave as first class citizens,
something that can't be easily done with the key,value approach.

Sat, 10 Feb 1996 01:02:39 GMT  
 [ 2 post ] 

 Relevant Pages 

1. Tcl shared libraries and static libraries

2. CAPI: access to data in shared library

3. BLOCK DATA subprograms in dynamic shared libraries

4. GOBO data structure library vs other data structure libraries

5. FORTRAN common in AIX shared library not shared at runtime (0/1)

6. MultiThread for data acquisition (basic problem)

7. C++ shared library & TCL

8. Create shared library for a Tcl package.

9. Building shared libraries with gcc 3.2 (cygwin or mingw) for Tcl 8.4.1

10. Tcl/Tk version numbers and shared libraries

11. Oracle Tcl question (shared library problem?)

12. Overriding CFLAGS in [incr Tcl] shared library build loses -fpic


Powered by phpBB® Forum Software