An observation regarding Lumiera's parallelism
Ichthyostega.. <
prg@...>
2012-02-08 17:34:27 GMT
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
_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
http://lumiera.org/donations.html
Cheers,
Hermann
_______________________________________________
Lumiera mailing list
RSS Feed