[DGD] Code libraries for DGD and Hydra

[Raymond Jennings]

In such a case the combatants would most likely have a fixed order or
initiative, so they should be done serially anyway.

I don't think combat is a good example of something that should be parallelized.
On Tue, Sep 18, 2018 at 9:44 PM Dread Quixadhal <quixadhal at gmail.com> wrote:
>
> 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
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd