[Lumiera] An observation regarding Lumiera's parallelism

Ichthyostega.. prg at ichthyostega.de
Wed Feb 8 18:34:27 CET 2012



Hi Lumi hackers,

since we're discussing about advertisement, and also consider GSoC, there's
an
interesting observation I want to share.

Mostly, wer're discussing our thread handling in the render engine along
the lines of
"we have isolated jobs and a scheduler, and those jobs are made to avoid
blocking".

While this is certainly true, it not the full story. When considered at a
higher,
more abstract level, what we're actually doing in our engine is some kind
of
"modified fork-join". The similarities are striking -- the major difference
is, that fork-join is a generic handling pattern and typically implemented
through general purpose libraries, while we're creating something
specialised
and dedicated here. Yet still

- we have a "backbone level", which does "fork" new sub tasks: while
playback
  is running, we won't schedule all conceivable jobs at once; rather we're
  scheduling the first chunk plus a follow-up job to schedule the next
chunk.

- we *do* join the results together. We just do it in a clever way, so to
avoid
  blocking waits. Our "join operation" is actually implemented by
comparison with
  a time of delivery / deadline. When in time, results can be dropped in,
otherwise
  they are just discarded

Thus, the most relevant difference is, that the classical fork-join pattern
uses
a stack or deque for the forked worker tasks, while we're using a priority
queue
with intelligent time-of-delivery based ordering.

Cheers,
Hermann




More information about the Lumiera mailing list