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
|