[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Threads in Octave

From: Przemek Klosowski
Subject: Re: Threads in Octave
Date: Tue, 10 Apr 2001 14:14:37 -0400

I reported:

   | The same code implemented as Octave extension (Octave 2.1.33) runs,
   | but the main process doesn't seem to return the correct thread ID from
   | pthread_self().

JWE wrote (and Ben Sapp confirmed) that

   I'm not sure why your simple example is failing.  It seems to work for
   me on a Debian system.  

We pretty much blame glibc 2.1. Glibc 2.2 works correctly for this 
case, but has other problems; there's more on it below.

JWE further writes

   However, if your more complicated example calls back to Octave, I
   wouldn't expect it to work, since the Octave interpreter and libraries
   were definitely not designed to be thread safe.

We have instrumented tk_octave by Joao Cardoso to run in a thread.
The main thread runs octave, and the second thread runs the Tcl/Tk
interpreter. We get concurent Octave and Tcl event loops, without the
inconvenience of a separate process. The Tcl interpreter is full-featured,
and can load binary Tcl extension packages (such as BLT and Vtk).

So far we haven't seen any negative interaction between threads: the
only potential contention area is I think the C library, and new
versions of glibc are thread safe.  Of course, in light of what JWE is
saying, calling liboctave from the Tcl thread is probably a bad idea,
but we don't need that: we use Tcl from Octave by passing commands to
the Tcl interpreter in the Tcl thread, and we can use Octave from Tcl
by doing the opposite.

Because both threads share the address space, the Octave data is
accessible to Tcl. Normally, if we used Tcl string/list representation
this wouldn't be exciting, but we started using the BLT widget set and
its vector data type, so the data movement for graphing is rather
snappy (and remember that we recently implemented BLT error bars, so
it's now mature enough for scientific data graphing). BLT can do
interactive manipulations (such as zooming/panning) on graphs with
thousands of points w/o too much trouble.

We haven't really looked into portability of our approach. It should be 
doable: Tcl/Tk has been ported to Windows/Mac; pthreads are also available,
I think, at least on NT+/OSX. BLT's graph has been ported to at least Windows,
and should also be available on the Mac, but we won't have the wherewithal
to actually put these ports together, so we'd be looking for collaborators.

Assuming  x=1:100; y=sin(x/10), a typical sequence for plotting might be:

        tk_cmd("package require BLT; pack [blt::graph .g]; Blt_ZoomStack .g");
        tk_cmd("vector x y");   o2v(x,"x");     o2v(y,"y");
        tk_cmd(".g element create E; .g element configure E -xdata x -ydata y");

In other words, start up Tk and then BLT, create a graph with an
interactive zoom capability; create BLT vectors, and transfer data
from Octave; create a line element in the graph, with the data from
the previous step.

This doeesn't necessarily compare favorably with plot(x,y), but
gives much more flexibility in the construction of the plot layout,
as well as interactive zooming, easier printing, etc.
We have also implemented loading the Tk photo image from octave arrays
(for both the image and colormaps).

We haven't touched the 3D visualization tools from the Vtk toolkit
yet, but that's next on the list.

So, these are the good news; now for the bad news. Using glibc 2.1
we had problems with inter-thread synchronization (mutexes and 
condition waits weren't working correctly). Using glibc 2.2 made that
work right, but with glibc 2.2, octave 2.[12], Tcl 8.2 and XFree86 4.x
we are getting X errors of the form 

  XIO:  fatal IO error 0 (Success) on X server ":0.0"
    after 359 requests (358 known processed) with 0 events remaining.

which seem to be associated with non-thread-safe X libraries (even though
Xfree86 4.x is supposed to be thread safe). We aren't X experts so we
have given up for now---if someone knows X well, please help us! we
are looking at other implementations of X to see if they also exhibit
the problem, but we don't know yet.

We have worked around this issue, by using glibc 2.1 and doing
inter-thread synchronization via SIGUSR1---so we actually do have
a nice alternative GUI/visualization environment for octave.

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]