Date: Tue, 14 Oct 2003 16:02:25 +0300 From: "Peter Dimov" To: "Boost Users mailing list" Subject: Re: [Boost-users] shared_from_this

Dragan Milenkovic wrote:

...

Hello, people,

I've been using enable_shared_from_this a LOT, mostly for implementing the Observer pattern (an object holds a list of weak pointers to it's observers).

[snip]

...

Also, any comments on the designs I used? Better observers?

It is hard to say; you'll need to go into more detail about the observers. If they are only notified on destruction of the observed entity, the typical shared_ptr approach is to reverse/eliminate the dependency and make the observers store weak pointers to the "observee".

For other notification scenarios, there is the usual tradeoff between polling and messaging. I prefer polling most of the time since this eliminates the need to store an observer list and makes it possible to "observe" classes that weren't specifically designed for this, but there may be a performance cost.

Well this (new) question is about observers in general, concurrent programming and C++. I believe to be making my way up the learning curve, but this seems to be a bit of problem. The proper destruction... Here is what I've been thinking. First the destruction of the subject (observee). As proposed in "Design Patterns", the subject could notify the observers about being destroyed, so the observers can handle that situation. But in my (more or less limited) experience, most often the observer is the one that controls the life-time of the subject (possibly by the means of shared_ptr). So this really presents no problem... But how to synchronize the destruction of the observer with a nofication originating from another thread? The observer's destructor would most likely perform Subject::unregister... But a call to Observer::update might have already been dispatched... The possible solutions I can think of are: 1. Make Subject::unregister have a postcodition stating that the observer will receive notifications no more (as of the moment the function returns). The words that come into my mind while thinking of possible implementations are: mutex, condition, dead-lock, inconsistency... What should the observer be allowed to do from inside the update function? Inspect only? I guess that could work... 2. Subject holds weak_ptr<Observer> and removes dead observers. I like it because of simplicity, but it (possibly) requires that Observer inherits enable_shared_from_this. In my design, the subject usualy passes a pointer to itself in the Observer::update method... Better yet - a shared_ptr, as it is more clean to compare shared pointer, especially inside the container. And how does it get shared_ptr to itself? shared_from_this() again. Is it really necessary? Although it does make the code easier to maintain. I might be wrong, but I get the impression that there is not much information on multithreading and destruction in C++. Destruction the way it is, makes C++ my language of preference. The lectures usually starts with a queue or a buffer with one mutex and one (or two) conditional variables, but it doesn't get any better. How is the queue destroyed? What about consumer which is waiting on a conditional variable? What is the common way of dealing with all this? Java-like interrupt? That's basically what I've been doing. Many thanks, Dragan Milenkovic