Re: How do I make a thread-safe copy-constructor?
On Apr 26, 11:18 am, Vladimir Marko <swe...@post.sk> wrote:
On 26 Apr, 02:46, rich_sposato <r...@richsposato.com> wrote:
Can anybody suggest how to design a thread-safe copy-constructor?
The problem is how to make the copy-constructor work even as the
copied object gets deleted by another thread.
You can't.
If the source gets deleted, you are copying a non-existent object.
In general, if you pass data from one thread to another you must
ensure that the first thread won't destroy the data before the
second thread finished reading it. You failed to do that for the top
level object, so you can't expect the contained subobjects to be
copied correctly.
I came to a similar conclusion based on my own experiments. The
destructor in thread-1 can run through completion before thread-2 even
has a chance to enter the copy-constructor. The end result is that
the reference passed into the copy-constructor is already dead.
Even admitting that nothing can prevent that situation, ... I still
want to know if an implementation exists such that the copy-
constructor succeeds in all situations where thread-1 gets swapped out
while inside the destructor.
I looked at Boost's shared_ptr to see how that solves the problem. I
discovered that has an implementation similar to the first
implementation shown in my original post. Here is a snippet from
Boost's sp_counted_base_pt.hpp which implements the "thread-safe"
reference counting for shared_ptr.
void sp_counted_base::release() // nothrow
{
pthread_mutex_lock( &m_ );
long new_use_count = --use_count_;
pthread_mutex_unlock( &m_ );
if( new_use_count == 0 )
{
dispose();
weak_release();
}
}
Just wrap the calls to pthread_mutex_lock and pthread_mutex_unlock
inside a function called AtomicDecrement, and you're looking at my
original implementation. If the thread gets swapped out right after
the call to pthread_mutex_unlock and another thread tries to copy the
shared_ptr, then the target object ends up with a pointer to a dead
object.
As soon as I saw that inside Boost's implementation details, I stopped
assuming that Boost was thread-safe.
Thanks,
Rich
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]