Messaging vs. subroutines (changed/update problems)

Joachim Durchholz joachim.durchholz at munich.netsurf.de
Fri May 21 20:20:47 UTC 1999


Peter Smet wrote:
> 
> I notice that in Java objects lock their state
> until all dependents have received their changed notification.

Isn't this limited to inter-process calls? (Not sure about what Java
really does in this context.)

> This seems to reduce, but perhaps not elimate the problem.

Hm. It should make the problem obvious (by locking up the program, or
throwing a deadlock exception, or whatever Java does in case of such an
error), but it won't prevent it in the first place.

> Some objects may receive a changed notification and then query the
> changed object about what exactly changed. Before they get a chance to
> send their query, the sender may change state several times.
> 
> Circular updates can result in loops that never terminate:
> 
> loopy variableA: newValue.
>     variableA := newValue.
>     self changed: #variableA
> 
> loopyListener update: symbol
>          symbol == #variableA ifTrue: [loopy variableA: newValue].
> 
> Oracle solves this with a rule that an Object (a table in this case)
> that has triggered a change notification puts itself into a "mutating"
> state, and cannot do any more triggering until the first change
> notification is completed, and its state is no longer "mutating". This
> mechanism should prevent all endless message loops...

At the expense of possibly missing an update in the case of notification
circles.
I think update circles are a program error, and should be reported as
such.

> Synchronization is a difficult area, but one that Squeak will need to
> address sooner or later. Multithreading and distributed objects are
> the direction that things are heading in .

Agreed.

Regards,
Joachim
-- 
Please don't send unsolicited ads.





More information about the Squeak-dev mailing list