Callbacks accross different threads

Alfonso Morra wrote:

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

Alfonso Morra wrote:

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

Alvin wrote:

Alfonso Morra wrote:

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.

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

"Alfonso Morra" <sw***********@ the-ring.com> wrote in message
news:dg******** **@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...

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

Alfonso Morra wrote:

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.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

On Mon, 19 Sep 2005 12:40:10 +0000 (UTC), Alfonso Morra
<sw***********@ the-ring.com> wrote:

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::Listen er 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::Listen er:
class User: private Service::Listen er
{
public:
void Do(Service& service) { service.Do(*thi s); }

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

Mirek Fidler wrote:

Alfonso Morra wrote:

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

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

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

On 19 Sep 2005 19:33:44 -0700, "puzzlecrac ker" <ir*********@gm ail.com> wrote:

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