- Forum
- UNIX/Linux Programming
- Strange problem with member object in mu
Strange problem with member object in multple instances
Hi all,
I have multiple instances of my class created. All of them contain a private member object from the interface provided to me.
The problem I have now, is that if I let all instances run at the same time, they will all be racing for control over this object thus leave the system nonoperational.
I initially think mutex will solve the problem but that was not the case. I did some print out and found that all object from different instances are pointing to the exact same address...
I've never encountered this before. According to my understanding, different instances should hold different objects of their own. How can they "share" the object some how?
Any thoughts could be helpful.
Thanks.
Xephon
I have multiple instances of my class created. All of them contain a private member object from the interface provided to me.
The problem I have now, is that if I let all instances run at the same time, they will all be racing for control over this object thus leave the system nonoperational.
I initially think mutex will solve the problem but that was not the case. I did some print out and found that all object from different instances are pointing to the exact same address...
I've never encountered this before. According to my understanding, different instances should hold different objects of their own. How can they "share" the object some how?
Any thoughts could be helpful.
Thanks.
Xephon
Nah... it is not defined static.
I know static makes it shared. That's why I'm not doing so.
I know static makes it shared. That's why I'm not doing so.
Well, that would have been too easy! :) Perhaps there is something in the way your program is compiled and/or linked. Seeing some code might help! :D
| different instances should hold different objects of their own. How can they "share" the object some how? |
Sorry ne555, didn't quite get you... do you mean all those pointers somehow are just pointer copies in different instances pointing to the same object? this is the observation here, but shouldn't those be different objects? Or how can I make them different objects instead copied pointers?
I'm confused!
What is this shared object for?
Are you members actual objects, or pointers?
By say "interface", do you mean a vtable-only class?
As the description makes it most likely to be a pointer : if possible -- as new555 said -- you should do a deep copy, to avoid the problem.
Or does this object represents a shared resource? In that case, it would be valid for all objects to hold a pointer to it. But a mutex (or other control primitive) should be able to solve any access problems.
What is this shared object for?
Are you members actual objects, or pointers?
By say "interface", do you mean a vtable-only class?
As the description makes it most likely to be a pointer : if possible -- as new555 said -- you should do a deep copy, to avoid the problem.
Or does this object represents a shared resource? In that case, it would be valid for all objects to hold a pointer to it. But a mutex (or other control primitive) should be able to solve any access problems.
The object is a resource manager from the provided interface. That's the actual layer calling hardware functions as far as I concern.
This particular member is an actual object. I tried to use new function call to make it pointer. In this case, what is a deep copy? how can I do that? do you have a link?
Doesn't matter if I declare it an object or a pointer to a new allocated object using new, it is shared between different instances of my own class, aka, they have same memory address.
I tend to create a fresh manager for each instance I have instead of let them be a shared manager for the resource I have.
Another thing, the access to each manager IS in mutex protection as of now. Same problem remains.
This particular member is an actual object. I tried to use new function call to make it pointer. In this case, what is a deep copy? how can I do that? do you have a link?
Doesn't matter if I declare it an object or a pointer to a new allocated object using new, it is shared between different instances of my own class, aka, they have same memory address.
I tend to create a fresh manager for each instance I have instead of let them be a shared manager for the resource I have.
Another thing, the access to each manager IS in mutex protection as of now. Same problem remains.
When you make a deep copy of an object it means that all of it's member are fully copied. So you need to create copies of all the members which were created on the heap (with new) by (of for) the original instance. You reference to new suggests you are already doing a deep copy.
You mention hardware in your post. Is the address you refer to a port?
(Now I'm more awake : this question makes no sense for a normal - user mode - app...
As you are already using a mutex, I am left rather puzzled. Have you asked this question on your hardware provider's support forum?
As you are already using a mutex, I am left rather puzzled. Have you asked this question on your hardware provider's support forum?
Last edited on
I am actually waiting reply from the guy built the interface. If his api does not allow me creating multiple instances but treat it like a shared service, then there is my problem.
I have tried new and still, those members are pointing to the same address. A huge puzzle for me as well.
I was using printf("%p", ptr) for the address print out. Not sure if this is a "port" of your saying. I rarely use %p myself.
I got around by letting threads sleep for a while right after releasing the mutex. This works for one instance but still prevent some instances to access the manager if I have more than one running at the same time.
I have tried new and still, those members are pointing to the same address. A huge puzzle for me as well.
I was using printf("%p", ptr) for the address print out. Not sure if this is a "port" of your saying. I rarely use %p myself.
I got around by letting threads sleep for a while right after releasing the mutex. This works for one instance but still prevent some instances to access the manager if I have more than one running at the same time.
Scratch the question about the port; that must a problem for the interface code you're taking to, rather than you're app.
Last edited on
Topic archived. No new replies allowed.