Callbacks accross different threads

A

Alfonso Morra

This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)
 
A

Alvin

Alfonso said:
This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)

Perhaps using a mutex would help? For example, lock the mutex before calling
the callback routine. Then unlock it when you are done. This way you can
ensure that only one thread is using the callback at a time.

Just a thought,

Alvin
 
M

Mirek Fidler

Alfonso said:
This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)

Well, many GUI toolkits seem to reasonably assume just a single thread
for GUI and use queue (usually the same one as for timer events or
messages) to pass events (or callbacks) across threads.... This requires
just the queue to synchronized - MT aware, therefore I think that this
is quite a good solution simple solution.

Mirek
 
M

Mirek Fidler

Alvin said:
Alfonso Morra wrote:




Perhaps using a mutex would help? For example, lock the mutex before calling
the callback routine. Then unlock it when you are done. This way you can
ensure that only one thread is using the callback at a time.

Well, this has the problem to defining what the mutex should serialize....

E.g., if callback is directed towards some class (like calling some
method of instance), there probably should be one mutex per class and
should be locked for any public interface method call... Not a very easy
and effective solution...

Mirek
 
B

benben

Alfonso Morra said:
This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)

What platform your are on? I've been using COM appartment concept for a
while and maybe you can either use it or reimplement it.

Ben
 
J

Joe Seigh

Alfonso said:
This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)
You mean like Java which is OO plus threads? Just learn how to avoid
deadlock which is a problem in Java caused by naively making all method
calls synchronized without bothering to understand what locking is
used for and why and when it is or is not needed.
 
D

Dave Rahardja

This may be considered as OT since the C++ Standard says not one word
about threads. Nevertheless, C++ is routinely and widely used to write
solid multithreaded code.

I wondered if anyone has any pointers/references to invoking callbacks
accross different threads? (google is not showing much promise, and I'm
running out of both time and patience...)

I've used the following pattern successfully with a very complex multithreaded
application:


class Service
{
public:
class Listener
{
public:
virtual void Callback() = 0; // This is the callback function
};

void Do(Listener& listener);
};


The consumer of the service then creates a class that inherits from
Service::Listener to implement the callback, and pass an instance of it to
Do(), which will then call the Callback() method.

And in some cases, the User class can inherit privately from
Service::Listener:


class User: private Service::Listener
{
public:
void Do(Service& service) { service.Do(*this); }

private:
virtual void Callback() { /* ... */ }
};


The nice thing about this pattern is that the particular resource locking and
serialization knowledge is owned by the _user_ of the service, not the service
itself. This lends itself to services that will work in both lightweight (no
synchronization needed) and heavyweight (lots of synchronization needed)
applications with no change.

If you need to synchronize the use of the service, you can either add an
Open()/Close() pair of methods to Service, or add synchronization code inside
Service::Do().

-dr
 
A

Alfonso Morra

Mirek said:
Well, many GUI toolkits seem to reasonably assume just a single thread
for GUI and use queue (usually the same one as for timer events or
messages) to pass events (or callbacks) across threads.... This requires
just the queue to synchronized - MT aware, therefore I think that this
is quite a good solution simple solution.

Mirek

I like, I like!. Nice simple solution. I think it may just work. Tkx !
 
P

puzzlecracker

interesting pattern - what pattern is that? I think I had seen
somethign similar in Gamma's classic book.
 
D

Dave Rahardja

interesting pattern - what pattern is that? I think I had seen
somethign similar in Gamma's classic book.

I assume you're replying to my post (next time quote what you're replying to).

I guess the pattern is like a "reverse Bridge" pattern ;-)

Basically the strategy is for one part of the library to export an interface
which the user of the library implements.

That leaves the library free to make callbacks, and leaves the details about
what needs to be done when the callback occurs to the user.

-dr
 
R

red floyd

Dave said:
I assume you're replying to my post (next time quote what you're replying to).

I guess the pattern is like a "reverse Bridge" pattern ;-)

Basically the strategy is for one part of the library to export an interface
which the user of the library implements.

That leaves the library free to make callbacks, and leaves the details about
what needs to be done when the callback occurs to the user.

-dr

Also kind of like the Visitor, in that the behavior is determined by
external factors. In fact, isn't Visitor essentially a generic callback
that can be applied to each element of a data structure? Or am I
completely mixed up?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,013
Latest member
KatriceSwa

Latest Threads

Top