< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Reference Counting Smart Pointer


The desire to use a smart pointer is not for performance gains - it is to
easy the memory management burden of the application (for now - just for
UserProfile management).

There is a mutex to guard the counter logic.  For more info - check out:

http://www.boost.org/libs/smart_ptr/shared_ptr.htm

Here is a cut-and-paste of the thread safety section:

Thread Safety
shared_ptr objects offer the same level of thread safety as built-in types.
A shared_ptr instance can be "read" (accessed using only const operations)
simultaneously by multiple threads. Different shared_ptr instances can be
"written to" (accessed using mutable operations such as operator= or reset)
simultaneosly by multiple threads (even when these instances are copies, and
share the same reference count underneath.)

Any other simultaneous accesses result in undefined behavior.
....


-----Original Message-----
From: kaiduan xie [mailto:kaiduanx@xxxxxxxx] 
Sent: Thursday, May 26, 2005 4:27 PM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Reference Counting Smart Pointer

Will the smart pointer be used in multiple-thread
environment? If yes, you may need to add mutex to
serialize its access. But the overhead of serializing
operation may over-counter the performance brought
from shared pointer.

In VOVIDA, it used a lot of smarter pointer. But in
resiprocate, the smarter pointer was totally removed.
Any anyone explain the reason?

kaiduan