RE: [Boost-users] problems using shared_ptr in threads
Tristan King <tristanking@internode.on.net> wrote:
Hi, I'm having trouble getting shared_ptr objects and threads to work in harmony. <snip> i'm not worried about the order that the threads run in (as this is just an example of the problem i'm having in a simple multi-threaded web server i'm working on), but it seems like the shared_ptr object may be getting deleted before the last thread gets to execute.
Yes, that is what is happening. The problem is that your single_thread objects are destroyed at the end of the loop body. By the time the new thread runs its single_thread may have been destroyed along with all its members. Since each single_thread is constructed in the same block of memory, it is possible for the thread to pick up the value intended for the next thread. <snip>
can anyone give me any pointers on how to get around this problem? <snip>
I suggest you create your thread objects with 'new' instead, or else define an array of them outside the loop. Ben.
Ben Hutchings wrote:
Tristan King <tristanking@internode.on.net> wrote:
Hi, I'm having trouble getting shared_ptr objects and threads to work in harmony. [snip] can anyone give me any pointers on how to get around this problem?
<snip>
I suggest you create your thread objects with 'new' instead, or else define an array of them outside the loop.
Or just don't use boost:ref, and have the thread function objects copied. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Ben Hutchings wrote:
Tristan King <tristanking@internode.on.net> wrote:
Hi, I'm having trouble getting shared_ptr objects and threads to work in harmony.
[snip]
can anyone give me any pointers on how to get around this problem?
<snip>
I suggest you create your thread objects with 'new' instead, or else define an array of them outside the loop.
Or just don't use boost:ref, and have the thread function objects copied.
Rene, is that possible with a stuct? the problem is that i need give the thread some initial parameters, and i'm not sure if thats possible using a simple function. Ben's solution worked, however is probably not the best solution. as the number of threads called needs to be infinate (within physical limits of course). if a thread is created using new simple_thread* trd = new simple_thread( p ); and started using: threads.create_thread( boost::ref( *trd ) ); trd still needs to be destroyed using "delete" somewhere right? or will the memory be free'd when the thread finishes execution? is there anyway to check if a thread has ended and thus free the memory? otherwise using new generates too many memory allocations without reasonable memory deletions. and the program would soon run out of memory (unless i'm missing something here) thanks again --Tristan
Tristan King wrote:
Rene Rivera wrote:
Or just don't use boost:ref, and have the thread function objects copied.
Rene, is that possible with a stuct?
Yes, as long as it has default and copy ctors (or usually the auto generated ones).
the problem is that i need give the thread some initial parameters, and i'm not sure if thats possible using a simple function.
The most elegant solution is to use Boost.Bind. For example your original code could be written as such: #include <iostream> #include <boost/thread.hpp> #include <boost/shared_ptr.hpp> #include <boost/bind.hpp> void simple_thread(int i) { std::cout << i << std::endl; } int main() { boost::thread_group threads; for ( int i = 0 ; i < 5 ; ++i ) { threads.create_thread( boost::bind(&simple_thread,i) ); }; threads.join_all( ); return 0; }
if a thread is created using new simple_thread* trd = new simple_thread( p ); and started using: threads.create_thread( boost::ref( *trd ) ); trd still needs to be destroyed using "delete" somewhere right?
Yes.
or will the memory be free'd when the thread finishes execution?
No. HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (4)
-
Ben Hutchings -
Rene Rivera -
Tristan King