Multithreaded Observer Pattern

[clanmjc]

I'm about to build an (Observer/Subject) (Publisher/Subcriber) interface that I will reuse for different applications. This will be in C++, vintage, I have access to Boost 1.41.0.


I've implemented the pattern in a single threaded environment, I've used it in a multithreaded non c++ environment so I have some ideas of the constraints and tradeoffs of the pattern. I've also read many times over including today the Gang of 4 on the topic and googled around but I haven't been able to find the de-facto resource on the topic. (Multithreaded wise)

1) Anyone have some good links that talk about design considerations (it doesn't have to be in c++, however, if it is in another language an that language's constructs already alleviate the multithreaded problem then it isn't going to help me as much as a read that has to address the problem. e.g. Containers in some languages are thread safe, this doesn't help me address it in c++.

2) Has anyone here created a multithreaded Observer pattern that maybe we could discuss about design decisions, tradeoffs, choices that were made as a compromise... etc.

Some of the considerations are:
I will probably use a std::list for my observers(this may evolve into something else, still undecided if we will have a managing class for the observer/subject relationship.

The interface will start off simple. For now assume everything is syntactically correct...

class IObserver
{
    virtual void Notify(ITopic &) =0;
}

class ISubject
{
    virtual void Attach(IObserver *) =0;
    virtual void Detach(IObserver *) =0;
}

Considerations:
We could use one thread for the Subject, when a state changes that requires a notify it would lock then iterate over each observer and call notify. This is easy enough. However, this design has some major drawbacks, 1) the Notify will block all subsequent calls to Notify until it is done, this could take a while in some systems. 2) If the list of observers is massive, doing this in a sequence might be bad news for Observers near the end of the list. (There are other drawbacks but aside from it being very simple to implement, that is the only positive thing I can come up with for this design).

We could use a thread pool, this one I need to research a little more, it's possible that then notifies could be concurrent (because the action the observer takes during notify does not effect the subject OR any of the other observers) in some manner. If anyone has suggestions or info to add on this, that would be great. Would the threads run the notify in own thread etc...

Lock less, the problems we ran into here was when an Observer wants to detach, we would have to have a mechanism where the Subject would have to notify the Observer that it has successfully unregistered the Observer before the Observer could be deallocated.

Any suggestions, links, posts, examples even in the generalist idea would be appreciated as I'm just consuming all the pros and cons that I can on the topic right now.

[clanmjc]

boost::signals2 and boost::asio, it looks like a good combination for this, wondering if anyone has used to two together?

[Galik]

One thing that occurs to me is that when you notify your observers you could simply place the notification into a non-blocking queue (one for each observer) which the observer accesses from its own thread. That way notifications would be handed out relatively quickly during the list's lock and processed independently of the lock.