[vsipl++] Possible Threading Issue

Fri Feb 20 14:15:47 UTC 2009

Brad,

Sourcery VSIPL++ is not implicitly thread safe.  The primary place for 
race conditions is the reference counting associated with blocks.  Also, 
library initialization and use of backends may not be thread safe. 
However, if you're careful (initialize the library once, keep blocks 
local to a thread or protect actions that change the reference count of 
a shared block), things should work.

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.

Can you try the following simple test program?  If it works, it won't 
tell us much, but if it fails ...

				thanks,
				-- Jules

Brad Howes wrote:
> All,
> 
> Are there some guidelines for using VSIPL++ (vsipl-lite-2.0) in a 
> threaded environment? I'm seeing some bizarre behavior when trying to 
> allocate a new vsip::Vector<float>. The main thread starts up with
> 
>     vsip::vsipl vpp( argc, argv );
> 
> and then later spawns a worker thread. In that worker thread, I try:
> 
>     new vsip::Vector<float>( 1000, 0.0 )
> 
> and I get a NULL pointer for a Memory_pool object. This pool object is 
> from an map reference that has all NULL attribute values. Below is the 
> stack trace, for what it is worth. Any ideas would be most appreciated. 
> Thanks in advance!
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> [Switching to process 27854 thread 0x2703]
> 0x00d11cb9 in vsip::impl::Memory_pool::allocate<float> (this=0x0, 
> size=3000) at memory_pool.hpp:50
> 50      { return (T*)(impl_allocate(size * sizeof(T))); }
> (gdb) bt
> #0  0x00d11cb9 in vsip::impl::Memory_pool::allocate<float> (this=0x0, 
> size=3000) at memory_pool.hpp:50
> #1  0x00d11d02 in vsip::impl::Dense_storage<vsip::impl::Cmplx_inter_fmt, 
> float>::Dense_storage (this=0xc56190, pool=0x0, size=3000, val=0, 
> buffer=0x0) at dense.hpp:321
> #2  0x00d11db7 in vsip::impl::Dense_impl<1u, float, vsip::tuple<0u, 1u, 
> 2u>, vsip::impl::Cmplx_inter_fmt, vsip::Local_map>::Dense_impl 
> (this=0xc56190, dom=@0xb0102b14, val=0, map=@0xb0102c50) at dense.hpp:1381
> #3  0x00d1220e in vsip::Dense<1u, float, vsip::tuple<0u, 1u, 2u>, 
> vsip::Local_map>::Dense (this=0xc56190, dom=@0xb0102b14, value=0, 
> map=@0xb0102c50) at dense.hpp:644
> #4  0x00d1228b in vsip::const_Vector<float, vsip::Dense<1u, float, 
> vsip::tuple<0u, 1u, 2u>, vsip::Local_map> >::const_Vector 
> (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at 
> vector.hpp:75
> #5  0x00d12308 in vsip::impl_View<vsip::Vector, vsip::Dense<1u, float, 
> vsip::tuple<0u, 1u, 2u>, vsip::Local_map>, float, 1u>::impl_View 
> (this=0xc5c090, len=3000, value=@0xb0102c4c, map=@0xb0102c50) at 
> view_traits.hpp:244
> #6  0x00d12338 in vsip::Vector<float, vsip::Dense<1u, float, 
> vsip::tuple<0u, 1u, 2u>, vsip::Local_map> >::Vector (this=0xc5c090, 
> len=3000, value=@0xb0102c4c, map=@0xb0102c50) at vector.hpp:197
> #7  0x00d0888e in SideCar::Algorithms::NCIntegrate::process 
> (this=0xc24180, msg=@0xb0102d58) at 
> /Users/howes/sidecar/trunk/Algorithms/ncintegrate/NCIntegrate.cc:86
> #8  0x00d0f9b3 in boost::_mfi::mf1<bool, 
> SideCar::Algorithms::NCIntegrate, 
> SideCar::Messages::TPRIMessageRef<SideCar::Messages::Video> 
> const&>::operator() (this=0xb0102d14, p=0xc24180, a1=@0xb0102d58) at 
> bind/mem_fn_template.hpp:162
> #9  0x00d10beb in boost::detail::function::function_mem_invoker2<bool 
> (SideCar::Algorithms::NCIntegrate::*)(SideCar::Messages::TPRIMessageRef<SideCar::Messages::Video> 
> const&), bool, SideCar::Algorithms::NCIntegrate*, 
> SideCar::Messages::TPRIMessageRef<SideCar::Messages::Video> >::invoke 
> (function_obj_ptr=@0xc23a8c, a0=0xc24180, a1=@0xb0102d58) at 
> function/function_template.hpp:206
> #10 0x00d17b88 in boost::function2<bool, 
> SideCar::Algorithms::NCIntegrate*, 
> SideCar::Messages::TPRIMessageRef<SideCar::Messages::Video> 
>  >::operator() (this=0xc23a88, a0=0xc24180, a1=@0xb0102d90) at 
> function/function_template.hpp:989
> #11 0x00d18269 in 
> SideCar::Algorithms::TProcessor<SideCar::Algorithms::NCIntegrate, 
> SideCar::Messages::Video>::process (this=0xc23a80, msg=@0xb0102e38) at 
> Processor.h:64
> #12 0x0008ae8a in SideCar::Algorithms::Algorithm::process 
> (this=0xc24180, msg=@0xb0102e38, channelIndex=0) at 
> /Users/howes/sidecar/trunk/Algorithms/Algorithm.cc:139
> #13 0x00096867 in SideCar::Algorithms::Controller::processDataMessage 
> (this=0xc1a360, data=0xb92e20) at 
> /Users/howes/sidecar/trunk/Algorithms/Controller.cc:360
> #14 0x003cbd9f in SideCar::IO::Task::processMessage (this=0xc1a360, 
> data=0xb92e20) at /Users/howes/sidecar/trunk/IO/Task.cc:484
> #15 0x00095dca in SideCar::Algorithms::Controller::processOneMessage 
> (this=0xc1a360, data=0xb92e20) at 
> /Users/howes/sidecar/trunk/Algorithms/Controller.cc:490
> #16 0x00095f6d in SideCar::Algorithms::Controller::svc (this=0xc1a360) 
> at /Users/howes/sidecar/trunk/Algorithms/Controller.cc:511
> #17 0x0094af8d in ACE_Task_Base::svc_run (args=0xc1a360) at Task.cpp:275
> #18 0x0094b354 in ACE_Thread_Adapter::invoke (this=0xc246f0) at 
> Thread_Adapter.cpp:98
> #19 0x9610a095 in _pthread_start ()
> #20 0x96109f52 in thread_start ()
> 

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x-pthreads.cpp
Type: text/x-c++src
Size: 2044 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20090220/287974f2/attachment.cpp>