On Sat, 2009-09-05 at 12:08 -0400, John Cowan wrote:
> It's the combination of unrestricted mutation and unrestricted sharing
> that's poison.
> In Scheme we already have, for better and worse, the unrestricted
> mutation. If we get into unrestricted sharing as well, Cthulhu help us,
> for we shall be eaten next to last.
Should we consider a concurrency model with restricted sharing?
This would involve rules about what (shared) variables are "in scope"
in particular threads, with other threads not permitted to use them,
right? Or with particular threads having "write" access and other
threads having "read" access to the same variable?
It's a very good model for, eg, dataflow programming. In dataflow,
you have many parts of the computation connected by queues of data.[1]
Each of these steps can be its own thread, with read access to one
or two queues of data and write access to one or two queues of data.
Since only one thread has write access to any queue, the job can
be split up among any number of processors less than the number of
rendering steps with no lock contention.
Bear
[1]
think of a render pipeline: you have the world model as the basic
data where mutations such as relative movement of the models happens,
then the pipeline consists of geometric transformations for point
of view, z sorting, hidden face elimination, a fork in the
datastream where one side goes to shading and the other goes to
texture mapping, a rejoin in the data stream where both of those
are mapped to pixels, and the final step is blitting to the screen.
In this case the threads could be the geometric transformer, z
sorter, hidden face eliminator, shader, texture-mapper, and
pixel-mapper.
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
