Is there an Interlocked for this? C++

Question

Please note - these builds are for VS2008/VS2010 builds I cannot use any 11 constructs.

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.

//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()
   }
}

Line 3 - pointer is tested and is pointing to valid object. Before line 4 is executed, another thread NULLs the subscriber. Line 4 - Boom.

My Question, is there a way that I can use some sort of Interlocked something such that the test and call is atomic.

e.g. for a reference counted object in the destructor, something like this works

 RefCountObject::~RefCountObject(){
    if(InterlockedDecrement(&m_count) == 0)
      delete m_data;
 }

Here, the reference counter is decremented and tested against zero automically, then and only then if equal to zero, the data is released.

Is there a way for me to do this for calling a function based on the validity of a pointer?

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.

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.

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.

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.

If the subscriber can be deleted while you're walking the container, then you need a higher level of synchronization/lifetime management than a simple atomic test. Like a reference counter (as might be wrapped in a shared pointer, for example). Note that you also need to protect against the object being deleted *while* `notify()` is being executed. — Michael Burr, Sep 17 '12 at 21:12
Are you sure you actually need an atomic for this (instead of using a `mutex`)? Lockfree structures are notoriously hard to get right, particulary for more complex structures, so its often simply not worth the effort. In this case an atomic test and call (if such existed) wouldn't help you, since you can't guarantee that `subscriber` isn't deleted while the thread is inside the `notify`. — Grizzly, Sep 17 '12 at 21:16

score 3 · Accepted Answer · answered Sep 17 '12 at 21:14

3

is there a way that I can use some sort of Interlocked something such that the test and call is atomic.

For the test, yes there will be a way. You just want to compare a pointer.

To do the call, i doubt it. You will need a guard around the call, i.e. a Critical Section.

answered Sep 17 '12 at 21:14

Science_Fiction

3,403
23
27

We are trying to avoid a critical section, which is the motivation behind the question. It very well may not be possible. Thanks – clanmjc Sep 17 '12 at 22:07
We all try to avoid them to certain extents. But things cannot always be done atomically. Do some profiling using a Critical Section with a spin count. Critical Sections are "time consuming" when they lock, if it can go through freely and this happens most of the time in your app, the cost may be less than you think. – Science_Fiction Sep 17 '12 at 22:12
I hear you. We absolutely cannot hold a lock during a call to the notify, I may have to lock, copy a resource, unlock, call notify, clean up. Again trying to avoid this but it may not be possible. Spin Count, is there a rule of thumb for the time, is there a magic number you find yourself using? Thanks – clanmjc Sep 17 '12 at 22:41
The default is usually something like 4000 (on Windows anyway). I've seen something like the following used in Intel code samples though: spinCount = NumThreads * 1000; if (spinCount > 8000) spinCount = 8000; – Science_Fiction Sep 18 '12 at 08:57

score 0 · Answer 2 · answered Sep 17 '12 at 23:40

0

You can use a "smart pointer" strategy to do a deferred nulling of the pointer. As long as someone has a reference to the pointer, as determined by an interlocked reference count, keep the pointer valid; when the count goes to zero it's safe to null.

answered Sep 17 '12 at 23:40

Mark Ransom

299,747
42
398
622

Is there an Interlocked for this? C++

2 Answers2