Re-entrace condition for destructors

FJ

unread,

Jun 13, 2003, 6:05:19 AM6/13/03

to

Guys,
Could someone clarify this for me,

If i have a class that is supposedly threadsafe, then how do i ensure that
the destructor isnt called concurrently with any other member function of
that class - or is this ensured by C++ that this wont happen (tho' i dont
see how).
Critical sections and the like just won't cut it.
TIA,
-fj

Peter van Merkerk

unread,

Jun 13, 2003, 6:34:05 AM6/13/03

to

> If i have a class that is supposedly threadsafe, then how do i ensure
that
> the destructor isnt called concurrently with any other member function
of
> that class - or is this ensured by C++ that this wont happen (tho' i
dont
> see how).

No, C++ doesn't care about threads. You will have to make sure that
before an object is destroyed, no other threads will access that thread.
You will have to resolve this issue at a higher level.

Though mutexes can be used to prevent concurrent access to an object, it
doesn't solve the destructor problem. Let's say thread A is busy
destructing the object, and thread B calls a member function on the same
object. Mutexes can block thread B until the destructor running in
thread A has finished, but by the time thread B is unblocked the object
is already destroyed

Further questions regarding multithreaded programming are best asked in
comp.programming.threads.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

Alexander Terekhov

unread,

Jun 13, 2003, 6:37:10 AM6/13/03

to

FJ wrote:
>
> Guys,
> Could someone clarify this for me,
>
> If i have a class that is supposedly threadsafe,

Thread safe? Just like with exception safety, there's multiple "levels"
of thread safety. I call it "unsafe", "basic", and "strong".

http://groups.google.com/groups?selm=3ECD2B7D.BBC526FC%40web.de
(Subject: Re: shared_ptr/weak_ptr and thread-safety)

> then how do i ensure that
> the destructor isnt called concurrently with any other member function of
> that class - or is this ensured by C++ that this wont happen (tho' i dont
> see how).

It isn't ensured by C++. You shall simply synchronize it.

regards,
alexander.

Archimel

unread,

Jun 13, 2003, 3:34:55 PM6/13/03

to

This isn't really any different than the issue of calling a function on
a pointer to an object that has already been deleted, even in a
single-threaded application. You need to incorporate some way to get
rid of references to dead pointers in either case. You probably ought
to take a step back and clarify what the real issue is.

--
Posted via http://dbforums.com

FJ

unread,

Jun 14, 2003, 11:08:52 AM6/14/03

to

"Archimel" <membe...@dbforums.com> wrote in message
news:3000590.1...@dbforums.com...

Well, the real issue is just as you put it. I have a class factory handing
out pointers to objects across multiple threads, and the class-factory
itself is responsible for deleting the objects. Now i really dont mind
having invalid references out there, because the way the semantics work, the
threads should query the class factory *every time* before using the object
<i know this is really dumb...but reality sucks!>
No, the issue is that if i'm inside an object method, while the factory
decides to shut down, then i'm screwed <and it seems to be happening quite
often in a test case - so i'm quite majorly screwed already>. I just can't
figure how to work this out.

-fj

Alexander Terekhov

unread,

Jun 14, 2003, 1:23:30 PM6/14/03

to

Synchronize the shutdown. It's always a good idea. Well, as for the
factory and deletion, the following might provide you with some ideas:

http://groups.google.com/groups?selm=3D021EA4.E2217C09%40web.de
(Subject: Re: Objects in container: creation and deletion details)

regards,
alexander.