On 2017-02-25 12:12-0000 p.d.rosenb...@gmail.com wrote: > > >> But that failure (one or both semaphores are not blocked with zero >> values) should be impossible because the fact is both semaphores are >> initialized in that expected (blocked) state (that check succeeded for >> the initial call to moveBytesReaderReversed on the wxPLViewer side), >> and at the end of moveBytesReaderReversed when that header transfer >> succeeded (as measured on the -dev wxwidgets side) the check is made >> again that the semaphores are left in the proper blocked state. >
> Welcome to the world of multithread bugs and race conditions š. I haven't looked at the code but my first guess should be some sort of race condition. You cannot rely on any operation completing in one process before the other, unless you have an explicit check for it. I seem to remember having an initialisation flag in the shared memory that gets set by wxPlViewer to indicate all initialisation is complete and the viewer is ready for communication to begin. If you don't have a similar check then you canāt rely on things being ready, including the semaphores being initialised. Note that āovertakingā can occur anywhere, including midway through a single line of code. Hi Phil: Thanks for that welcome. :-) Last night my hypothesis (something clobbered) to explain why this "PLMemoryMap::moveBytesWriter: attempt to start transfer with semaphores not in correct blocked state." exception was being thrown went down in flames because I got an absolutely clean report from valgrind from both the -dev wxwidgets and wxPLViewer side. So your additional feedback concerning the likely possibility of race conditions to explain this bug was quite useful. I believe you are referring above in the -DPL_WXWIDGETS_IPC2=OFF case to wxPLViewer setting the viewerOpenFlag of the header to signal -dev wxwidgets that the wxPLViewer is properly initialized and -dev wxwidgets waiting to proceed until that flag is set. When you get a chance to look at the -DPL_WXWIDGETS_IPC2=ON code case, you will see that is exactly how moveBytesReaderReversed is initially used on the wxPLViewer side and moveBytesWriterReversed initially used on the -dev wxwidgets side. However, I certainly agree mutual use of the same resource (shared memory) is a tricky world. And now that you have encouraged me to think about races, I discovered there is indeed a race condition that could explain this bug. I have now worked around that race (commit 4e6932e) and please see that commit message for more commentary concerning this type of race. Assuming I really did understand this race, I am virtually positive my simple crude fix will deal with it without any noticeable reduction in speed. However, time will tell about that. So at this time I am pretty sure only two issues are left with the -DPL_WXWIDGETS_IPC2=ON case. One of those is to implement interactivity, and the other (which I plan to start working on now) is to deal with the issue (or issues?) where wxwidgets detects an uncaught exception being thrown every time examples 2 or 14 are executed. Thanks once again for your useful feedback above. 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
