Doubt about boost shared_ptr

[myfavdepo]

Hi all,
I have a query regarding the exchanging of a
boost::shared_p tr beween different threads. In my program i've two
threads both of which having their own internal queues for storing the
shared_ptr. one thread is meant to pass the shared_ptr to another after
its processing.

So when a message arrives i convert it into a class of
my own called 'Msg' and i put the 'Msg' object pointer into a
shared_ptr and put into the other thread's message queue. in that
second thread after starting the processing suddenly the program stops
responding. when i examined the log files and tried tracing, i noticed
that the 'shared_ptr' is getting destroyed just after it has been
released by the first thread after putting it into the second thread's
message queue. I am passing the shared_ptr as reference.

anybody knows what cud be the reason? or is it
that shared_ptr is not meant to work that way?

Sreehari

[kwikius]

myfavd...@gmail .com wrote:

I am passing the shared_ptr as reference.

anybody knows what cud be the reason? or is it
that shared_ptr is not meant to work that way?

I'm no expert on threads or boost::sherd_pt r but I would guess you
should pas it by value, not by reference. That should bump the use
count when its copied and keep it alive.

It would proably be best to try the boost users glist though.

regards
Andy Little

[Joe Seigh]

my*******@gmail .com wrote:

Hi all,
I have a query regarding the exchanging of a
boost::shared_p tr beween different threads. In my program i've two
threads both of which having their own internal queues for storing the
shared_ptr. one thread is meant to pass the shared_ptr to another after
its processing.

So when a message arrives i convert it into a class of
my own called 'Msg' and i put the 'Msg' object pointer into a
shared_ptr and put into the other thread's message queue. in that
second thread after starting the processing suddenly the program stops
responding. when i examined the log files and tried tracing, i noticed
that the 'shared_ptr' is getting destroyed just after it has been
released by the first thread after putting it into the second thread's
message queue. I am passing the shared_ptr as reference.

anybody knows what cud be the reason? or is it
that shared_ptr is not meant to work that way?

You're doing something wrong but it's not clear from your description what.
One thing is share_ptr needs locking or some other form of syncrhonization
to be shared between threads. The other is it's not clear how it being
put onto the second thread's queue. Are you putting a copy of the
shared_ptr onto the queue or a reference to the shared ptr onto the queue?
Sharing raw references to shared_ptr is as problematic as sharing raw
references to any object.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Pete Becker]

my*******@gmail .com wrote:

Hi all,
I have a query regarding the exchanging of a
boost::shared_p tr beween different threads. In my program i've two
threads both of which having their own internal queues for storing the
shared_ptr. one thread is meant to pass the shared_ptr to another after
its processing.

So when a message arrives i convert it into a class of
my own called 'Msg' and i put the 'Msg' object pointer into a
shared_ptr and put into the other thread's message queue. in that
second thread after starting the processing suddenly the program stops
responding. when i examined the log files and tried tracing, i noticed
that the 'shared_ptr' is getting destroyed just after it has been
released by the first thread after putting it into the second thread's
message queue. I am passing the shared_ptr as reference.

anybody knows what cud be the reason? or is it
that shared_ptr is not meant to work that way?

I think Kwikius nailed it. In general, shared_ptr objects should be
passed by value, so they can properly manage the controlled resource. If
your queue is holding a reference, that doesn't count: when the
shared_ptr object that it refers to goes out of scope the reference has
nothing to refer to.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[myfavdepo]

Thanks everyone. I was passing the shared_ptr using reference at first.
Then i changed to pass by value. And now it seems to be working fine.
Can somebody give me how the destructor is
actually gets called? i mean, exactly when and by which thread calls it
in case of a multi-threaded program?

Regards,
Sreehari

Pete Becker wrote:

my*******@gmail .com wrote:

Hi all,
I have a query regarding the exchanging of a
boost::shared_p tr beween different threads. In my program i've two
threads both of which having their own internal queues for storing the
shared_ptr. one thread is meant to pass the shared_ptr to another after
its processing.

So when a message arrives i convert it into a class of
my own called 'Msg' and i put the 'Msg' object pointer into a
shared_ptr and put into the other thread's message queue. in that
second thread after starting the processing suddenly the program stops
responding. when i examined the log files and tried tracing, i noticed
that the 'shared_ptr' is getting destroyed just after it has been
released by the first thread after putting it into the second thread's
message queue. I am passing the shared_ptr as reference.

anybody knows what cud be the reason? or is it
that shared_ptr is not meant to work that way?

I think Kwikius nailed it. In general, shared_ptr objects should be
passed by value, so they can properly manage the controlled resource. If
your queue is holding a reference, that doesn't count: when the
shared_ptr object that it refers to goes out of scope the reference has
nothing to refer to.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Pete Becker]

my*******@gmail .com wrote:

Thanks everyone. I was passing the shared_ptr using reference at first.
Then i changed to pass by value. And now it seems to be working fine.
Can somebody give me how the destructor is
actually gets called? i mean, exactly when and by which thread calls it
in case of a multi-threaded program?

When the last shared_ptr object that manages a particular resource is
destroyed, the resource also gets destroyed.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Joe Seigh]

my*******@gmail .com wrote:

Thanks everyone. I was passing the shared_ptr using reference at first.
Then i changed to pass by value. And now it seems to be working fine.
Can somebody give me how the destructor is
actually gets called? i mean, exactly when and by which thread calls it
in case of a multi-threaded program?

When the share_ptr drops its reference by being assigned another value,
and it sees the previous object's reference count drop to zero. So any place
you assign another value to the shared_ptr could potentially call the
dtor and you need to ensure that the dtor is safe to invoke in those
places.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Chris Thomasson]

Here is a good alternative to Boost's non-atomic shared pointer:

http://appcore.home.comcast.net/vzoom/refcount/

?

Currently, Boost doesn't provide support for atomic reference counting;
shared_ptr<Tfal ls under 'basic' thread-safety. I propose a reference
counting algorithm that falls under 'strong' thread-safety. Here is a
experimental prototype I created:

http://appcore.home.comcast.net/vzoom/refcount/
A SPARC 32-64 version is underway. Here is some more information on my
algorithm:

http://groups.google.com/group/comp....8717d3bcdedfe9
(initial idea; pseudo-code)

http://groups.google.com/group/comp....21a151d3916592
(mostly lock-free...)

http://groups.google.com/group/comp....22ef08ae26e2f3
(async-signal-safe aspects of my algorithm)

http://groups.google.com/group/comp....7b1867c19e6288
(async-signal...)

http://groups.google.com/group/comp....e468f341a33ee2
(adding more async-signal-safety characteristics '...)

http://groups.google.com/group/comp....a46f3ef24b786a
http://groups.google.com/group/comp....63f874241bcaf4
(possible improvements... )
Does anybody think that Boost could possible benefit from this level of
thread-safety? Any thoughts?


Thank you all for you time!

Here are some more links:

http://search.gmane.org/?query=&auth...+thomasson---A
--
Chris Thomasson

http://appcore.home.comcast.net/
(portable lock-free data-structures)