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.
Best,
Dave 12 1909
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: meng |
last post by:
is it possible to use a single connection object shared by several
tasks where each task is handled by a thread? these tasks call stored
procedures that return record sets, no editing, update or...
|
by: Rick |
last post by:
Hello,
Below I create a static instance of an object, works well.
public static BasicCounter GlobalCounter = new
BasicCounter("GlobalCounter");
private void Page_Load(object sender,...
|
by: marc |
last post by:
>From the book I am using as a reference I understood that applet tag
was deprecated, but googling for information, and testing myself, it
seems IE does not work properly with this new object tag....
|
by: Michael Moreno |
last post by:
Hello,
In a class I have this code:
public object Obj;
If Obj is a COM object I would like to call in the Dispose() method the
following code:
...
|
by: anonymous.user0 |
last post by:
The way I understand it, if I have an object Listener that has
registered as a listener for some event Event that's produced by an
object Emitter, as long as Emitter is still allocated Listener...
|
by: eyoung |
last post by:
I call a function that takes the unit price and quantity ordered to
create an amount...it looks something like this.
function calculateCost()
{
quantity=document.RFO.quantity.value;...
|
by: atomik.fungus |
last post by:
Hi
I've made a kamikaze function wrapper that executes the function(s)
when its constructor is called and ends calling its own destructor. I
thought originally of this as a good idea to avoid some...
|
by: Joe Mayo |
last post by:
I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only...
|
by: Astley Le Jasper |
last post by:
Sorry for the numpty question ...
How do you find the reference name of an object?
So if i have this
bob = modulename.objectname()
how do i find that the name is 'bob'
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |