[DGD] Another mudlib requirement

[Felix A. Croes]

"Steve Foley" <zeppo1 at mindspring.com> wrote:

> "Felix A. Croes" <felix at dworkin.nl> wrote:
>
> > The latter will probably modify the object, and if it commits before
> > any of the callout-adding threads, they will be cancelled because
> > they accessed a version of the object's state which is now out of
> > date.
>
> How much discrimination will DGD be able to make in this regard?  I can imagine
> reading one member of an array (arr[0]) in one thread (thread A) while another
> thread (thread B) modifies a different array member (arr[5]).  If thread B
> commits before thread A, will thread A be rescheduled as a consequence of thread
> B?  Assume thread A doesn't assign arr to a local or global, and doesn't pass it
> as a parameter in a function call.

In theory, the granularity could be brought down to individual array
elements.  The basic procedure is as follows: each thread works on a
copy of the actual data.  When the thread is ready to finish, all the
'data entities' it has accessed are checked, and if no other
modifications have been committed to them since the thread started,
the thread will commit its own modifications.  Otherwise, the changed 
data copy is discarded and the thread is rescheduled.

In DGD/MP, the granularity is just below objects.  An object is divided
into its entry in the global object table, its LPC-level data, and
its callout table.  Additions (not deletions) to the callout table
receive special treatment, so that they can be executed in parallel;
among other things this means that callouts added from different
threads will always have different callout handles.

Doing this for individual array elements would be possible, but then
there would also be the administrative overhead of keeping track, for
each array element, of which thread last modified it.

For the LPC programmer it all boils down to two simple rules:

 - try to break up threads that access many objects, using callouts
 - try not to access objects that you add callouts to in any other way

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd