Can an object know it is dead?

"be***********@yahoo.com" <be***********@yahoo.comwrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

It cannot be done portably. However you might try putting in a "dead"
flag that is set to true in the destructor, then in all the
member-functions assert( dead == false ) might work.

An alternative that is standards conforming is to set-up a locking
mechanism. A simple map<void*, size_twill work. Whenever an object
needs another (or itself) to stay alive, it increments the value in the
map associated with that object. In the destructor, the object can check
to make sure that its reference is zero. Something like this:

map<void*, size_tlock;

class Object {
~Object() {
assert( lock[this] == 0 );
}

void func() {
++lock[this];
// do work
--lock[this];
}
};

void user( Object* o ) {
++lock[o];
// work with 'o'
--lock[o];
}

Of course it is wise to wrap the increment and decrement in an object
(RAII)

class Locker {
const void* obj;
Locker( const void* obj ): obj(obj) {
++lock[obj];
}
~Locker() {
--lock[obj];
}
};

On Feb 23, 10:54 am, "better_cs_...@yahoo.com"
<better_cs_...@yahoo.comwrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

Ignoring the threads aspect of this, the simplest way is to add a
private bool member and an isValid() member function:

[untested code]

class yourClass {
private:
bool valid_;
protected:
bool isValid() { return valid_; }
public:
yourClass() : valid_(true) {}
~yourClass() { valid_ = false; }
// Rest of yourClass
};

Now have each member function check isValid() before proceeding. For
debugging purposes, you might just add an assert(isValid()); to the
beginning of each member function.

Threads make this much more complicated of course - you would need
some sort of mutex or other device to ensure that the object wasn't
destructed while in the member function.

Best regards,

Tom

be***********@yahoo.com wrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

Can't be done.

Smart pointers.

In article <11**********************@q2g2000cwa.googlegroups. com>,
"Thomas Tutone" <Th***********@yahoo.comwrote:

On Feb 23, 10:54 am, "better_cs_...@yahoo.com"
<better_cs_...@yahoo.comwrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

Ignoring the threads aspect of this, the simplest way is to add a
private bool member and an isValid() member function:

[untested code]

class yourClass {
private:
bool valid_;
protected:
bool isValid() { return valid_; }
public:
yourClass() : valid_(true) {}
~yourClass() { valid_ = false; }
// Rest of yourClass
};

Now have each member function check isValid() before proceeding. For
debugging purposes, you might just add an assert(isValid()); to the
beginning of each member function.

Threads make this much more complicated of course - you would need
some sort of mutex or other device to ensure that the object wasn't
destructed while in the member function.

Best regards,

Tom

The above isn't "standards-compliant" as requested. If another object is
created in the memory space vacated by the dead object, valid_ may be
true even though the object is dead.

Daniel T. wrote:

In article <11**********************@q2g2000cwa.googlegroups. com>,
"Thomas Tutone" <Th***********@yahoo.comwrote:

>Ignoring the threads aspect of this, the simplest way is to add a
private bool member and an isValid() member function:

[untested code]

class yourClass {
private:
bool valid_;
protected:
bool isValid() { return valid_; }
public:
yourClass() : valid_(true) {}
~yourClass() { valid_ = false; }
// Rest of yourClass
};

>
The above isn't "standards-compliant" as requested. If another object is
created in the memory space vacated by the dead object, valid_ may be
true even though the object is dead.

And how is this different than your "solution"?

Daniel T. wrote:

"be***********@yahoo.com" <be***********@yahoo.comwrote:

>Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

It cannot be done portably. However you might try putting in a "dead"
flag that is set to true in the destructor, then in all the
member-functions assert( dead == false ) might work.

No, it won't. It will randomly fail.

On Feb 23, 11:17 am, Noah Roberts <u...@example.netwrote:

better_cs_...@yahoo.com wrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

Can't be done.

I doubt I'm telling Noah anything he does not already
know. But clueless newbies (me last week) might not
know why it can't be done.

It can't be done internally to the destroyed object.
If the destructor has been called then accessing the
data members of that object is an undefined operation.
Anything an object will "know" after it has been
destructed is not reliable. Indeed, even accessing
could, in principle, cause problems, even aside from
the contents not being defined. It could, for example,
produce some such thing as an access violation, and
so produce a program crash that is difficult to
understand. Or, it could result in the object being
quite happy to run along as though it were not
destructed, if another part of the code reset that
memory location. That might well produce very hard
to debug behaviour.

The only way to keep track of such things is to
put some kind of resource guard around the creation
and destruction of the object. That is, you have
to keep track externally to the object.

Smart pointers.

An example of doing it externally to the object.
Socks

In article <er**********@aioe.org>, Noah Roberts <us**@example.net>
wrote:

Daniel T. wrote:

In article <11**********************@q2g2000cwa.googlegroups. com>,
"Thomas Tutone" <Th***********@yahoo.comwrote:

Ignoring the threads aspect of this, the simplest way is to add a
private bool member and an isValid() member function:

[untested code]

class yourClass {
private:
bool valid_;
protected:
bool isValid() { return valid_; }
public:
yourClass() : valid_(true) {}
~yourClass() { valid_ = false; }
// Rest of yourClass
};

The above isn't "standards-compliant" as requested. If another object is
created in the memory space vacated by the dead object, valid_ may be
true even though the object is dead.

And how is this different than your "solution"?

With my solution, an assert will fire if some part of the code attempts
to destroy an object that is in use. I agree though that it allows one
to attempt to use an object that was destroyed and that needs to be
fixed. Here is a revised version:

map<void*, size_tlock;

class Object {
Object() {
assert( lock.find(this) == lock.end() );
lock[this] = 0;
}
~Object() {
assert( lock[this] == 0 );
lock.erase( this );
}

void func() {
assert( lock.find(this) != lock.end() );
++lock[this];
// do work
--lock[this];
}
};

void user( Object* o ) {
assert( lock.find(o) != lock.end() );
++lock[o];
// work with 'o'
--lock[o];
}

With the above, if you attempt to destroy an object that is still being
used by someone, an assert will fire and if you attempt to create an
object in a memory location that is in use, an assert will fire.

Of course it is wise to wrap the increment and decrement in an object
(RAII)

class Locker {
const void* obj;
Locker( const void* obj ): obj(obj) {
assert( lock.find(obj) != lock.end() );
++lock[obj];
}
~Locker() {
--lock[obj];
}
};

Daniel T. wrote:

In article <er**********@aioe.org>, Noah Roberts <us**@example.net>
wrote:

>Daniel T. wrote:

>>In article <11**********************@q2g2000cwa.googlegroups. com>,
"Thomas Tutone" <Th***********@yahoo.comwrote:
Ignoring the threads aspect of this, the simplest way is to add a
private bool member and an isValid() member function:

[untested code]

class yourClass {
private:
bool valid_;
protected:
bool isValid() { return valid_; }
public:
yourClass() : valid_(true) {}
~yourClass() { valid_ = false; }
// Rest of yourClass
};
The above isn't "standards-compliant" as requested. If another object is
created in the memory space vacated by the dead object, valid_ may be
true even though the object is dead.

And how is this different than your "solution"?

With my solution, an assert will fire if some part of the code attempts
to destroy an object that is in use. I agree though that it allows one
to attempt to use an object that was destroyed and that needs to be
fixed. Here is a revised version:

map<void*, size_tlock;

class Object {
Object() {
assert( lock.find(this) == lock.end() );
lock[this] = 0;
}
~Object() {
assert( lock[this] == 0 );
lock.erase( this );
}

void func() {
assert( lock.find(this) != lock.end() );
++lock[this];
// do work
--lock[this];
}
};

void user( Object* o ) {
assert( lock.find(o) != lock.end() );
++lock[o];
// work with 'o'
--lock[o];
}

With the above, if you attempt to destroy an object that is still being
used by someone, an assert will fire and if you attempt to create an
object in a memory location that is in use, an assert will fire.

Of course it is wise to wrap the increment and decrement in an object
(RAII)

class Locker {
const void* obj;
Locker( const void* obj ): obj(obj) {
assert( lock.find(obj) != lock.end() );
++lock[obj];
}
~Locker() {
--lock[obj];
}
};

Your fixed version is also not portable. Any and all uses of a deleted
object illicit undefined behavior. It also offers 0 protection in a
non-debug environment. Concurrent programs are affected by too many
variables for this to work even in cases when it might in a serial
program. What needs to be done here is to make sure the object is not
deleted before it is done being used. To do that, the easiest method is
some kind of smart pointer such as boost::shared_ptr (if such is thread
safe and I don't know). Even pooling could fall prey to the same
problem if a thread deletes the pool before those working with objects
in it are done.

So even by standard your solution doesn't work. When you add in the
OP's requirements it is even less suitable.

be***********@yahoo.com wrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

Thanks in advance for all responses.

Use reference counted objects and smart pointers to such objects.
The reference counting must be done in a thread-safe manner -- e.g.
there are special functions in Windows to increment/decrement an
integer -- I don't know about UNIXs -- you probably have to use a
normal integer and a mutex.
The object will be destroyed when the last smart pointer is destroyed.
If you want an explicite delete function reference counted objects are
also helpful.
Implement the delete function in the container of your objects.
Container::deleteChild(unsigned int ID);
Child::getID(void) const;
ID must be a unique integer for every container.
Allow only delete if the objects reference count is 1 -- e.g. if
nobody else than the container holds a reference.

Noah Roberts <us**@example.netwrote:

Daniel T. wrote:

With my solution, an assert will fire if some part of the code attempts
to destroy an object that is in use. I agree though that it allows one
to attempt to use an object that was destroyed and that needs to be
fixed. Here is a revised version:

map<void*, size_tlock;

class Object {
Object() {
assert( lock.find(this) == lock.end() );
lock[this] = 0;
}
~Object() {
assert( lock[this] == 0 );
lock.erase( this );
}

void func() {
assert( lock.find(this) != lock.end() );
++lock[this];
// do work
--lock[this];
}
};

void user( Object* o ) {
assert( lock.find(o) != lock.end() );
++lock[o];
// work with 'o'
--lock[o];
}

With the above, if you attempt to destroy an object that is still being
used by someone, an assert will fire and if you attempt to create an
object in a memory location that is in use, an assert will fire.

Of course it is wise to wrap the increment and decrement in an object
(RAII)

class Locker {
const void* obj;
Locker( const void* obj ): obj(obj) {
assert( lock.find(obj) != lock.end() );
++lock[obj];
}
~Locker() {
--lock[obj];
}
};

Your fixed version is also not portable. Any and all uses of a
deleted object illicit undefined behavior.

There is no use of any deleted object in the above code.

It also offers 0 protection in a non-debug environment. Concurrent
programs are affected by too many variables for this to work even in
cases when it might in a serial program.

All concurrent programs are by definition, non-portable so I don't see
where that has much to do with it.

What needs to be done here is to make sure the object is not deleted
before it is done being used.

Which is what my code does.

On 23 Feb, 15:54, "better_cs_...@yahoo.com" <better_cs_...@yahoo.com>
wrote:

Hello all,

I suspect that a threading issue is leading to an object being
destructed in one thread context while one of its member functions is
still running in another thread context. As a means of confirming
this, I would like to have the object check if it is alive in the
referenced member function and report to me if it is not. However, I
cannot think of a standards-compliant way for an object to know that
it has been destructed.

Can anybody confirm that this *cannot* be done? If it cannot, can
anybody suggest any alternatives?

For objects you wish to track, create them on the heap. Keep a
separate permanent table of the address of each with a flag regarding
its life. Never return the allocated memory. Use a static function of
the base object to look up the status of its this pointer, which if
necessary converts the offset to the base address of the object.

Alternatively manage and access the object via a combination of
boost::shared_ptr and weak_ptr.

regards
Andy Little