multi-threaded Observer

Is there a multi-threaded Observer pattern documented anywhere?

My problem is that the thread that runs the notify loop is sometimes held
hostage by an observer that is not ready to be called.

My proposed solution is for each observer to have an input buffer and an
internal thread. The internal thread is asleep until a message arrives in
the input buffer. The notify thread doesn't have to wait until each
observer is done processing the message, it can move on as soon as it
deposits the message in the observer's buffer.

I would use the Command pattern for the messages, except I don't want to
give the heap a work out. My messages are sent once a second, for weeks or
months on end. Therefore my circular buffers in the observers will be
allocated at program startup.

Bill

"Bill Burris" <wburris@ualberta.ca> skrev i en meddelelse
news:bmn50g$2r$1@tabloid.srv.ualberta.ca...
> Is there a multi-threaded Observer pattern documented anywhere?
>
> My problem is that the thread that runs the notify loop is sometimes held
> hostage by an observer that is not ready to be called.
>
> My proposed solution is for each observer to have an input buffer and an
> internal thread. The internal thread is asleep until a message arrives in
> the input buffer. The notify thread doesn't have to wait until each
> observer is done processing the message, it can move on as soon as it
> deposits the message in the observer's buffer.

How about creating an unix-pipe shared between the subject/observer threads?

Some problems with message-queues:
* how many messages should the queue be able to contain ?
* what to do when the message-queue is full ?

> I would use the Command pattern for the messages, except I don't want to
> give the heap a work out. My messages are sent once a second, for weeks
or
> months on end. Therefore my circular buffers in the observers will be
> allocated at program startup.

Does your message have a fixed size ? or is it variable ?

--
Simon Strandgaard

"Simon Strandgaard" <none> wrote in message
news:3f906cb1$0$70010$edfadb0f@dread12.news.tele.dk...
> "Bill Burris" <wburris@ualberta.ca> skrev i en meddelelse
> news:bmn50g$2r$1@tabloid.srv.ualberta.ca...
> > Is there a multi-threaded Observer pattern documented anywhere?
>
> Some problems with message-queues:
> * how many messages should the queue be able to contain ?
> * what to do when the message-queue is full ?
>

Normally there will be only one message in the queue. Time and date info
from a GPS receiver is set to the GUI and also to another routine where it
is merged with data from the data acquistion system before being saved to
disk.

When the data acquistion is idle, (before the user clicks the run button), I
still want the GPS info to arrive at the GUI. In this case the GPS data
arriving in the merge queue should be discarded.

The GUI is written in C# and the data acquistion is written in native C++.
Since the C# code is managed code, the garbage collector runs occasionally.
The time critical threads from the data acquistion layer should not enter
managed code because they will be suspended while the garbage collector
runs. If more then 1 message sits in the display queue the older ones might
as well be discarded since the user only needs to see the most recent
information.

With the solution I proposed in the previous message, each observer would
deal with the complexity of deciding when to process or discard the message.
The notify routine would be kept as a simple loop, pumping out messages and
not have to worry about what each observer does with the data.

Bill

>I would use the Command pattern for the messages, except I don't want to
>give the heap a work out.

In what sense may a Command be held equivalent to a Message?
My conception of the two is quite distinct, since Message completely
lacks the active behavioral properties of Command.

If I understand things correctly, Command is a pattern that gets
executed in the context of a receiver and then actually does
something.
Message instead only holds passive data which might get interpreted by
the receiver who then could carry out some action by itself.

Command to me is somewhat similar to email attachments from unknown
senders. I either can execute the attachment without having any clue
of what it might be capable of doing or simply discard it.
Message on the other hand leaves responsibility for taking action
completely to myself, with the risk of me not knowing what to do with
the information contained in the message.

My huge problem with the Command pattern lies in the pretty tight
coupling between the sender and the receiver of the Command. Suppose
an application with two seperate components, one of them being some
kind of rendering engine, the other the GUI. The rendering engine must
confirm to a certain interface to be compatible with the GUI - or to
put it another way: the GUI must know, which Commands it is permitted
to send to the rendering engine and which will fail (like "printf" in
a graphical environment).

Can this close coupling be loosened somehow?

Kind regards,
Malte Persike

---

The above e-mail address is not valid.
To contact me, please use my real
e-mail address:

malte AT t DASH online DOT de

Just replace the capitalized words with
the corresponding punctuation marks.