[DGD] Code libraries for DGD and Hydra

[Dread Quixadhal]

It sounds like a fun way to test this would be a combat situation where you had a large group of actors who were all doing area effect attacks that would hit each other.  In that case, if you had a group of 20 all standing in range of each other, each one would be dealing out damage to 19 others and having 19 occurrences of damage incoming (assuming nobody misses).

The part where it becomes fun is that you likely want a death event to occur once (and only once) for any actor who drops below a threshold of health, and you may want the one who landed the death blow to shout out in victory.  So each attacker has to know if their damage was the fatal blow.

In a boring non-message based system, you’d be doing things like if( (victim.health -= damage) <= 0 ) dance();

In a more usual LPC system, you might do something like if( victim->receive_damage(damage) <= 0 ) dance();

But to try and minimize collisions for parallel processing, I’m sure you’d need a different approach.  Perhaps having to make the victory dance become a callback that the victim’s object would invoke as the death blow were processed?

Sent from Mail for Windows 10

From: Felix A. Croes
Sent: Tuesday, September 18, 2018 9:13 PM
To: dgd at dworkin.nl
Subject: Re: [DGD] Code libraries for DGD and Hydra

When writing code for Hydra, one has to keep one thing in mind: the
current task may fail to commit, and have to be rescheduled, if one
or more of the objects accessed by the current task were modified by
another task, running concurrently.

This can be prevented by keeping the number of objects accessed by
the current task low.  Tasks that access many objects can be broken
up into smaller subtasks, chained together by callouts.

In Hydra, a callout added to an object does not count as a
modification of that object, as long as the state of the object (the
variables and other callouts) is not read or changed from the same
task.  The cloud library simplifies this with the call_out_other
function:

    call_out_other(obj, func, args...)

Any externally callable function in an object can be called in this
way.  The callout is always started with delay 0.

Multiple callouts can be added by a task, even to the same object.
For instance, a message could be passed to all users in a game
(potentially affecting a very large number of objects, which normally
would be very likely to fail to commit) with call_out_other(),
without increasing the likelyhood of the task to fail.

As a special case, consider an object which is central in some way,
and which has to be updated often by a variety of tasks.  Normally,
such updates would run a high risk of causing the task to fail to
commit.  But when call_out_other() is used, the calls are indirect,
and the central object can process the update from the
callout-started task.  Hydra can efficiently manage a large number of
pending callouts per object.

Call_out_other() can also be used to implement the map/reduce
coding pattern.  One object chops up a large dataset, adds callouts
with chunks of the data to a large number of other objects, those
objects process the chunk of data within the callout-started task,
and then report back to the originating object using another callout.
The originating object aggregates the results step by step, until all
the results are in.

There is one caveat.  Naturally, using status(obj) counts as
accessing the objects state, and therefore it is one of the things
that call_out_other() is not doing.  But status(obj) includes
information about callouts, and querying this state will explicitly
cause a collision with any changes to those callouts made by other
tasks.  Thus, status(obj) and status(obj)[O_CALLOUTS] become very
expensive operations.

Other than that, call_out_other() makes tasks composable on Hydra,
in a manner that prevents collisions between tasks.

Regards,
Felix Croes
____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd