1

I designed some class. It's like this:

  1. The class ClientEntity can have multiple instances.
  2. When a ClientEntity object is created, it will not be modified, so I don't use the mutex.
  3. ClientEntity objects can be accessed between different threads.
  4. ClientEntity objects will be destroyed when they receive some quit commands.
  5. ClientEntity objects may be accessed by some threads.

How can I destroy this object safely?

class ClientEntity
{
public:
    conference_info & conf_info (){return conf_info_;}
    void conf_info(const conference_info &ci){conf_info_ = ci;}

    user_info & usr_info(){return usr_info_;}
    void usr_info(const user_info &ui){usr_info_ = ui;}

private:
    web_conf_info *wci_;
    user_info usr_info_;
    conference_info conf_info_;

    // .....
};

class user_info
{
public:
    user_info & operator = (const user_info &ui)
    {   
        if (this != &ui){
            user_id = ui.user_id;
            user_name = ui.user_name;
            user_role = ui.user_role;
        }   

        return *this;
    }   
public:
    int user_id;
    int user_role;
    std::string user_name;
};


class conference_info
{
public:
    conference_info & operator = (const conference_info &conf)
    {   
        if (this != &conf){
            conf_id = conf.conf_id;
            dtsip_list = conf.dtsip_list;
            ctsip_list = conf.ctsip_list;
        }   

        return *this;
    }
public:
    int conf_id;
    std::list<std::string> dtsip_list;
    std::list<std::string> ctsip_list;
};
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
bbg
  • 321
  • 1
  • 6
  • By the very definition of your posted usage case, the only way to "safely" destroy the object is to ensure no usage can/will happen for that specific instance again. I.e. no thread has an outstanding finger in the pie before you eat it. – WhozCraig Jan 31 '13 at 02:42
  • 1
    `shared_ptr` is your friend. Alternatively, if the objects aren't too large, and immutable (ie. cannot be modified as you put it), make copies of them. – didierc Jan 31 '13 at 03:16

3 Answers3

1

The typical way to determine that you can (or can't) delete a shared object is to use reference counting - either by use of a "shared pointer", or as part of your own logic in the class itself. You will have to have some sort of function that is used by the client code to say "I want to use this object", that increments the reference count. When the client is finished, it calls the "I'm no longer interested in this object" and the reference count is counted down. If reference count becomes zero (and the object isn't needed for other reasons) it can be deleted.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Do you have some other solutions? – bbg Jan 31 '13 at 02:50
  • What particular aspect isn't good with my suggested solution? It's good enough for virtual memory pages in the Linux operating system, and is commonly used for graphics solutions (e.g. textures and surfaces in OpenGL and similar). – Mats Petersson Jan 31 '13 at 02:53
0

I suggest when creating the ClientEntity object, you should make sure it is correctly owned by another object, say a global object, and when the global object get destroyed, delete the ClientEntity.

Of course you can delete the ClientEntity at any time between multiple threads, but when you are trying to delete the ClientEntity, use synchronization object like critical section.

Other threads that access the ClientEntity should use critical section etc also, to prevent the object gets deleted when it is being used.

Zhi Wang
  • 1,138
  • 4
  • 20
  • 34
0

I have used my own classes which do reference counting. And I did a search and found that this could be used:

Example to use shared_ptr?

http://www.boost.org/doc/libs/1_52_0/libs/smart_ptr/shared_ptr.htm

Community
  • 1
  • 1
Gavin Palmer
  • 1,220
  • 15
  • 25