[vsipl++] Possible Threading Issue

[Brad Howes]

On Feb 20, 2009, at 9:15 AM, Jules Bergmann wrote:

> The error you're getting typically occurs if VSIPL++ hasn't been
> initialized.  If VSIPL++ is initialized, and if the threads share  
> their
> global address space, something else must be clearing that default  
> pool
> somehow.


Jules, thanks for the info. I *think* the problem is how our DSP  
framework loads algorithms, and this may only be a problem on MacOS X  
systems. We have one application that reads in an XML file and  
dynamically loads in various algorithm DLLs depending on the signal  
processing chain defined in the XML file. Our application definitely  
has the proper VSIPL++ initialization, but I think what is happening  
is that due to the static linkage of the VSIPL++ library, there might  
be multiple copies of some of the VSIPL++ symbols, one set in the DLL  
and another in our application binary. When we load the DLL via  
dlopen(), I'm not sure what VSIPL symbols are being used or  
initialized. Note that there could be multiple algorithm DLLs loaded  
by the application depending on the XML configuration.

My workaround for MacOS X that seems to work is to build libsvpp and  
libvsip_csl as dynamic libraries instead of archives. There may be  
some Darwin-specific g++ or ld flags I could use with the static  
archives to fix my problem, but I'm not that familiar with the nuances  
of shared libraries under Darwin.

Regards,

Brad

-- 
Brad Howes
Group 42
MIT Lincoln Laboratory • 244 Wood St. • Lexington, MA 02173
Phone: 781.981.5292 • Fax: 781.981.3495 • Secretary: 781.981.7420