Looking for Thread-Safe Observer Pattern

Get answers to all your basic programming questions. No Ogre questions, please!
Post Reply
iblues1976
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

Looking for Thread-Safe Observer Pattern

Post by iblues1976 »

Hi,

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

Thanks
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Looking for Thread-Safe Observer Pattern

Post by 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
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

Re: Looking for Thread-Safe Observer Pattern

Post by 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
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Looking for Thread-Safe Observer Pattern

Post by 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.
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: Looking for Thread-Safe Observer Pattern

Post by 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...
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Looking for Thread-Safe Observer Pattern

Post by Klaim »

stealth977 wrote: 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.
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: Looking for Thread-Safe Observer Pattern

Post by 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...
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Looking for Thread-Safe Observer Pattern

Post by Klaim »

stealth977 wrote: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
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

Re: Looking for Thread-Safe Observer Pattern

Post by 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.
Post Reply