Re: [Algorithms] General purpose task parallel threading approach

[Nicholas \Indy\ R. <ar...@gm...>]

On Thu, Apr 9, 2009 at 7:32 PM, Jon Watte <jw...@gm...> wrote:
> Only if you legislate that reactions to events can only happen on the
> next frame. Else, you may have an event of type A that triggers an event
> of type B, and another event of type B that triggers an event of type A,
> and you can't get a static order that solves both.
> For example: grenades exploding may put things on fire, but things
> burning may also explode grenades. Only in a system where you tie-break
> by introducing latency would you be able to use a static ordering.
> Meanwhile, in a system where work items are actual individual items
> (rather than static "pulsed" state machines or whatever), either case
> will be resolved within the same frame.

I understand it's true that situations arise where it is easy to loose
said order of events. But in my experience most of such events are put
off until the next frame anyways, even in single threaded engines.

Indy