Looking for Thread-Safe Observer Pattern

[iblues1976]

Hi,

Does anyone has observer pattern, thread-safe that could share?

Thanks

[Klaim]

I have several implementations for different use case. Do you have a specific use case?

One example of such system would be boost::signals2 : http://www.boost.org/doc/libs/1_57_0/do ... nals2.html

Not the most efficient but easy to use and you can build more complex dispatching mechanisms over it.

[iblues1976]

Any of your implementations of the observer pattern.


The use case is input device produces an event ... subscriber listen to the even

event E , eventdata D

I have a working prototype but it wasn't designed for threads. I modified it but I wasn't quite happy with it... I'm going to write a new one but I wanted to see if I could use an existing implementation.
thanks

[Klaim]

Did you look at boost signals? It's a pretty common pattern that should solve your problem.

Also, which version of C++ do you use? So I can give you an example that you can actually use.

[stealth977]

It all depends on your threading style. Do you use step synced threads? Do you use an independent thread for your input? Do your listeners run on a different thread?

You can only use boost::signal if both your listener and input is running on same thread, if they run on different threads boost signal would be a disaster. In that case you would need a message queue instead.

But again, it all depends on your threading style...

Assuming you would want to run input on a separate thread, you would need a message queue implementation where you push your input messages into (with time stamps). How you fetch messages from that queue depends on threading style again. If you have lock steps, then at some point (where your threads sync) you can process and deliver the queue messages to your registered listeners. If you dont have a sync point for your threads, then you would need classic OS style pulls from the queue where the listeners need to query the queue for any message they are interested in...

[Klaim]

You can only use boost::signal if both your listener and input is running on same thread, if they run on different threads boost signal would be a disaster. In that case you would need a message queue instead.

Not Boost.Signals2 which is thread-safe (the original signals library have been considered deprecated by the community for a long time). But I agree that the practice of working with tasks pushed in work queues on reactions is very good in a lot of cases. For example, I combine both in my current projects.

Here is a simplist (no disconnection) implementation of a signal in C++14 (for brievety): http://coliru.stacked-crooked.com/a/cdd0a741a76d94e9

as stealth977 points, it might not be the best way to do it depending on your use case.

[stealth977]

By disaster I didnt mean problem with boost::signal. What I meant was the listener will have problems in the invoked function since the invoked function will be called from another thread, you will need to implement explicit locking for any variables/functions used in the invoked function which is not a proper way of doing multi-threading IMO. But again the term multi-threaded does not mean that there is a single way of implementing it, actually its more of a general term and there are infinite different implementations of it...

[Klaim]

By disaster I didnt mean problem with boost::signal. What I meant was the listener will have problems in the invoked function since the invoked function will be called from another thread, you will need to implement explicit locking for any variables/functions used in the invoked function which is not a proper way of doing multi-threading IMO. But again the term multi-threaded does not mean that there is a single way of implementing it, actually its more of a general term and there are infinite different implementations of it...

Thanks for the clarification.
Inded, as you already pointed the common pattern is ton make sure the callback is protected too. I tend to endup synchonizing everything with work queues and I end up doing

signal.connect(wrap(work_queue, callback)); // make sure the callback is called in the work queue

a lot.

[iblues1976]

To reply to a previous question in this thread, the use case is for any type of input device that needs to send messages to subscribers that may be on different threads.