Probably the biggest issue is the use of plsc. Consider two threads which both set different streams then call another plplot function function. Between the first thread's call to set the stream and it's subsequent call to the other function it is entirely likely that the second thread will change the current stream. The nightmarish issues are obvious. This type of one object per calling thread problem seems to be dealt with by having some sort of handle which is passed in as the first item of each call. Generally this is a void * for opacity. Libcurl does this from memory. So we would need something like a plstreamcreate function which returns a void* pointer to a plstream and is passed in to each subsequent call for that stream, then a plstreamfree function would be used to free the memory.
At the moment it would probably be possible to make the C++ binding thread safe if not thread friendly as we can control exactly when plsc is set. This means we could stop the erroneous change of the current stream, but we could not have two streams being concurrently run in two threads i.e. one would get blocked and we would only be able to have one thread within PLplot at any given time. I'm not sure we would ever want to use threads internally within PLplot. For example to speed up calculations of contours. This is perhaps more of a vectorization issue that could be dealt with by compilers but might need #pragma statements which are compiler dependent. Phil On 23 March 2015 at 21:48, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-03-23 14:02-0400 Jim Dishaw wrote: > >> Last time I looked, achieving thread safety at a plot stream level > > should be achievable with modest effort (eliminating globals and > static arrays). Achieving thread safety within a plot steam is more > challenging and would require a fair number of mutex controls. > > Hi Jim, > > I am sure you are right, but could you expand on that statement so I > would better understand the development challenges that we would face? > For example, I am interested in the question of whether (1) it is a > fundamental misdesign of PLplot that requires it to have all those > mutex controls for thread safety so that the better choice would be to > change the design or (2) are there so many positives concerning the > present design compared to more naturally thread-safe alternatives > that the only choice we should consider for thread safety is those > mutex controls? > > 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 > __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
