multiple processes, one model

[Bert Freudenberg]

Am 29.03.2006 um 06:53 schrieb Chris Muller:
>> What if another session modifies something while a commit is in
>> progress? Could this lead to problems? I guarded the commitAndBegin
>> in a mutex, though.
>
> I'm afraid so.  If the model changes while its being serialized the
> serialized graph emitted from the serializer will not be a
> time-coherent representation of the model.  It could actually have an
> invalid oid reference in the commit-package and Magma will signal a
> commit error.
>
> Regrettably, I don't think a mutex only around commitAndBegin will
> guarantee safety under the shared-model approach.  You said you were
> single user, so it should be fine.  You could even get lucky with
> multiple users if no one changed the same parts of the model.

Could I somehow cancel the commitAndBegin? Like, using WriteBarrier I  
should be able to detect immediately if the model was changed while  
committing.

Or, another possibility, let the write barrier use the same mutex  
like my commitAndBegin. Thus, while it is committing, every write  
access of another thread would block until the commit is over.

> But without lower-level synchronization built into the language, this
> is living dangerously.  Wrapping the commit in a #valueUninterruptably
> or #valueUnpreemptively might actually help, crazy stuff though.

That sounds easiest, if it works, yes.

> When each Seaside session has its own copy of the model, multiple
> processes are not an issue, and Magma sees them as independent clients
> so the concurrency detection works too.  It is the only approach with
> potential to scale to multi-machines / processes as described on the
> Magma Seaside page.

Understood, but I'm still trying to avoid a complete SqueakSource  
rewrite.

- Bert -