Thread: [Plplot-devel] Thread safety

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

@Phil: I am particularly interested in your reaction here because you
had the idea before that you could implement PLplot in a thread-safe
way by using C++ as the core language, i.e., rewriting PLplot in C++.
I don't rule out the possibility, but one intermediate step toward
that goal might be to implement the idea below in C, and and then
change our C++ binding so that it automatically uses a PLplotContext
(which would presumably go a long way toward solving your current
issues with PLplot thread safety and wxwidgets).

@Everybody: now on to my C idea for thread safety.

The PLplot core C library is currently not thread safe, and I think we
are all agreed that it is important to address that issue since it is
an important barrier to entry for some. For example, if I recall
correctly it was Ruby on Rails developers who publicly expressed that
they wanted no part of PLplot because of this thread safety issue, and
presumably other library developers are silently avoiding PLplot for
this same reason. In addition, once it becomes possible to use PLplot
in a thread-safe way, it should make life much easier for Phil's
development work on the wxwidgets device.

We would go a long way toward thread safety if we got rid of all
static variables so the rest of this post focuses on that issue from
the C perspective.

My idea for implementing that (closely following what was done for the
C ephcom library case where David Howells implemented an ephcom
context to help provide an API that did not depend on static
variables) is to eliminate all static variables by using a
PLplotContext struct that contains all data that is currently stored
as static variables.

Once that is implemented then the proper non-static way to use PLplot
would be to do something like the following:

PLplotContext * context;

context = CreatePLplotContext();
plparseopts(..., context);
plinit(context);
// other ordinary PLplot calls as usual but with
// context as last argument, e.g.,
plline(..., context);

plend(context);

where CreatePLplotContext would malloc a PLplotContext, and all the
PLplot API calls would refer to that extra context argument whenever
they needed access to any part of what were previously static variables
(e.g., such as plsc).

The context-sensitive plend would do everything that plend currently does plus
destroy the context by freeing it.

So far this follows pretty exactly what David Howells implemented for
ephcom.  Does everybody agree this general idea (a comprehensive API
change where a context argument was added to every function call) would
go a long way toward making PLplot thread safe?

We found in the ephcom case that both the Python and Fortran bindings
for ephcom could pass the C pointer to a context as arguments.  So we
could implement those bindings in a non-static way using the ephcom
equivalent of CreatePLplotContext above. But we retained the static
version of the API just in case some future binding of ephcom was for
a language that could not pass C pointer arguments, and we would also
want to retain the static API for similar reasons in the PLplot case.

For static versions of plinit, plinit variants (e.g., plstar), and/or
all PLplot routines that can legitimately be called before plinit
would call CreatePLplotContext internally if the static variable
PLplotContextAddress was non-NULL and store that pointer in
PLplotContextAddress which would be referenced by every static PLplot
routine (but PLplotContextAddress would be completely ignored by the
non-static API).

For backwards compatibility (e.g., to support those who don't care
about thread safety and who do not want to change their code) we would
want to retain the same name for the static API that are used
now.  But I would like to use the same names for the non-static cases
as well if that is possible (say by following the approach discussed
at <http://stackoverflow.com/questions/1472138/c-default-arguments>.)

Further discussion is encouraged and welcome! Also, I am well aware I
have glossed over lots of details here.  That is because I frankly
don't completely understand all those details!  :-) Nevertheless,
assuming I have expressed the overview correctly of what would be
required, I hope someone will be inspired by that overview to go ahead
and implement the non-static C alternative as a very large step toward
the ability to use our library in a thread-safe way.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

---------- Forwarded message ----------
Date: Tue, 10 Dec 2002 02:52:43 -0600 (CST)
From: Maurice LeBrun <mj...@ga...>
To: Alan W. Irwin <ir...@be...>
Cc: PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] plinit, plend, plinit sequence now works,
     but I am having second thoughts

I can't tell you the specific answer to your questions due to how maniacally
busy I am these days (having just joined Lightspeed Semiconductor), but I can
elucidate some of the plplot design ideas that have historically been
un-documented.  And, I can give it in an object-oriented context, which
(because it is "canonical") is a lot nicer than the "this is the way it should
work" approach I've used historically. :)

This also includes proposals for change to how we do it now -- i.e. the
behavior of plinit().  I've always been somewhat bothered by the way stream 0
vs stream N is handled (this bugged me back in '94 but I wasn't exactly
swimming in free time then either).

When plplot starts, you have the statically pre-allocated stream, stream 0.
Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper
data-structure/object (in the plframe widget I automatically start from stream
1).

So stream 0 is like a class definition and an instance rolled into one.  What
I think we need to do is get rid of the "instance" part of this and leave
stream 0 as a "class definition" only.  In this case all the command line
arguments and initial pls...() calls (before plinit) serve to override the
default initializion of the class variables, i.e. set stream 0 parameters only

In other words, stream 0 becomes the template for all plplot streams.  You can
use it, but once you've called plinit() you have your own "instance" of the
plplot "object" -- i.e. you have a new stream with all the relevant state info
copied from stream 0.  If you change it, it dies when your stream dies with
plend1().

If you really want to change stream 0 (i.e. the "plplot object" "class data")
you can always set your stream number to 0 and fire away.

To summarize:

plinit() creates a new stream, copied from stream 0
plend1() deletes that stream
plend() deletes all streams, except of course stream 0 which is "class data"

Let me know if any of this helps.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Thread: [Plplot-devel] Thread safety

Cross-platform, scientific graphics plotting library

plplot-devel