StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POIs there an Interlocked for this? C++
text
Body
copied!<p>Please note - these builds are for VS2008/VS2010 builds I cannot use any 11 constructs.</p> <p>Imagine I have subscribers listening to some publisher. My publisher has a container of subscriber pointers. In my void detach(ISubscriber *), instead of locking the subscriber list, I will "NULL" out the pointer, for lack of a better word, for that subscriber.</p> <pre><code>//My container in the publisher. Inserts to not invalidate, removals only invalidate iterators pointing to the removed element, for this reason we NULL Container<ISubscriber *> myContainer; Now in the publisher... void NotifySubscribers(){ foreach(subscriber in container){ if(subscriber)//This is my problem subscriber->notify() } } </code></pre> <p>Line 3 - pointer is tested and is pointing to valid object. Before line 4 is executed, another thread NULLs the subscriber. Line 4 - Boom.</p> <p>My Question, is there a way that I can use some sort of Interlocked something such that the test and call is atomic.</p> <p>e.g. for a reference counted object in the destructor, something like this works</p> <pre><code> RefCountObject::~RefCountObject(){ if(InterlockedDecrement(&m_count) == 0) delete m_data; } </code></pre> <p>Here, the reference counter is decremented and tested against zero automically, then and only then if equal to zero, the data is released.</p> <p>Is there a way for me to do this for calling a function based on the validity of a pointer?</p> <p>Edit 1: I need to clarify a little based on the comments and thank you for your replies. The publisher is not responsible for the "releasing of memory" of the Subscribers, so there will be no leak. After the notify, the publisher will go through a loop that cleans up the container by removing nulled out subscribers.</p> <p>Now as for the subscribers themselves. When they detach, they are just detaching from listening to the publisher. They themselves will live on in static objects (This is the contract we are requiring). Why? Because we cannot afford to hold a lock during notification. The only other option was to use Share_Ptr, which was decided not to be incorporated into this DLL, due to versioning in the future.</p> <p>I created a hand written shared_ptr, but then it occurred to me that any reference to an object that was not wrapped in a resource management class would fall into the same pitfall and just push the "requirement" that subscribers would have to make sure to not refer to any dangling references within their implementation of said subscriber.</p> <p>Which brings us back to just saying, subscribers cannot be "released", and currently all the clients that will use this are static objects. We were just looking towards the future. Some of the users are legacy apps and would not be easy to bring in enabled_shared_from_this etc.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload