Observer pattern issue

[cstratelos]

Hello,

I have a question that concerns the Observer Design Pattern.

Why does every book and article that I have read on the topic does not
consider the fact that when the Observable notifies its Observers it
goes through a loop without starting a new thread for its Observer.

What I'm saying is that when you register with an Observable for
notifications, you do not want to depend on other Observers, that may
have already registered before you, to consume the notification
asynchronously.

For instance if there is only one Observer that has registered before
you then when the Observable will go through the loop:

Pseudocode:

foreach Observer o in myObservers
o.notify()

So if that first Observer takes forever to return from the notify()
call, or even worse never returns, you, who registered second, will
never get the notification.

Any thoughts??

thanx
costrat

 

[VisionSet]

So if that first Observer takes forever to return from the notify()
call, or even worse never returns, you, who registered second, will
never get the notification.

Any thoughts??

I guess it is the observers responsibility to return quickly, if it needs
longer then the observer should launch its own thread.
I expect there are circumstances where observers can be considered to be
untrusted, and if this were the case then perhaps there is a case for a
threaded notification pattern, especially since everything I have read
always makes clear not to expect the notifications to happen in any
particular order.

 

[Robert Klemme]

Hello,

I have a question that concerns the Observer Design Pattern.

Why does every book and article that I have read on the topic does not
consider the fact that when the Observable notifies its Observers it
goes through a loop without starting a new thread for its Observer.

What I'm saying is that when you register with an Observable for
notifications, you do not want to depend on other Observers, that may
have already registered before you, to consume the notification
asynchronously.

For instance if there is only one Observer that has registered before
you then when the Observable will go through the loop:

Pseudocode:

foreach Observer o in myObservers
o.notify()

So if that first Observer takes forever to return from the notify()
call, or even worse never returns, you, who registered second, will
never get the notification.

Any thoughts??

IMHO there are several reasons against making spawning threads the
default:

- if any of the observers object the operation (=> exception) this won't
work

- the average implementation of a notifier method is quite lean and
usually won't result in those problems you see; for these the overhead of
creating another thread can be significant, especially if done often

- executing notify calls in concurrent threads makes synchronization
necessary all over the place

Kind regards

robert

 

[Thomas Weidenfeller]

Why does every book and article that I have read on the topic does not
consider the fact that when the Observable notifies its Observers it
goes through a loop without starting a new thread for its Observer.

Because it is not relevant. If you need asynchronous notification it is
trivial to notify each subscriber on its own thread ...

.... and it complicates issues significantly, particular because the
observers have to be aware of the thread and need synchronization.

So if that first Observer takes forever to return from the notify()
call, or even worse never returns, you, who registered second, will
never get the notification.

Like with all code, you make certain assumptions. E.g. that an observer
returns in a timely fashion. Like with all code, you don't guard against
every remotely possible failure.

/Thomas

 

[cstratelos]

What I'm saying is that I cannot rely on other people's implementation
of Observer.
I feel that the pattern is broken.

An equivalent of this in the real world would be a subscription to a
newsletter.
Someone tells you to subscribe to their newsletter, but you will only
get it if all the subscribers before you acknowledge receiving it...

Costas

 

[Robert Klemme]

What I'm saying is that I cannot rely on other people's implementation
of Observer.
I feel that the pattern is broken.

If you take that thought just a step further you're not allowed to use any
libraries - and that includes those that come with the JDK. In every
piece of software there are numerous ways to screw the whole thing up
(actually you don't need multiple people for this ). Does it break
patterns if they are not properly implemented? I don't think so:
implementations are broken - or they use the wrong pattern.

Regards

robert

 

[Chris Uppal]

Why does every book and article that I have read on the topic does not
consider the fact that when the Observable notifies its Observers it
goes through a loop without starting a new thread for its Observer.

Observer pattern is intended to decouple the Observeer from the Observer --
that's to say that in /software engineering/ terms one doesn't depend on the
other. You can make changes to the implementation of either with little risk
of breaking the other.

But that's protecting against changes to the code or to the design. Observer
pattern is /not/ intended to provide protection (at runtime) against buggy or
malicious code. Observers are expected to be coded to conform to the obvious
requirements. If not then they are broken and should be fixed before release.

Now, it isn't absurd at all to consider an extension to the Observer pattern
that /does/ provide more protection. But, (A) it is rarely needed. (B) it
would require complex and slow code in the Observee. (C) It could make the
Observers much more complicated if they couldn't assume that notifications were
still valid at the time they received them. (D) It isn't clear /what/
protection is needed -- depending on the application it might suffice to call
the notification method with a catch-all try/catch block around it; or you
might need to start a new thread for each notification; or you might want to
run the Observer code in a separate OS Process; or even on a different
machine...

The typical Observer implementation is designed to handle the simple and (by
far) most common case. Other implementations can be created at need, but --
and this is point -- there isn't often any need.

-- chris