送交者: AA 于 2005-9-28, 23:18:07:
回答: Does the sync cost lots of resource? 由 xj 于 2005-9-28, 10:22:05:
There are many new languages invented for parallel programming, but none of them have succeeded. I believe the main reason is programmer's (or human being's) way of thinking. We don't reason things in parallel, and we don't reason one thing and its interactions with other things in parallel. We always think one thing after another, then we think their interactions. This suggest a programming model that, as a programmer, I only create sequential programs ("linear process oriented" in your words), then I connect them. Just like what I do when I am drawing a diagram, I draw the boxes or circles first, then draw the lines between them.
You are right, Java can't support this model directly. But it doesn't prevent we from using Java to build a development environment that can support this model. There is a work (by a UK university) called JCSP using Java to build CSP programming environment.
But you may find that, this model has no real difference from Object oriented programming, because in OOP, people just draw the classes, and connect the classes (objects) with function invocations. UML is designed for this that programmer can draw a diagram, then the tool can hopefully generate the codes for you.
The real difference is, in OOP, you don't have a way to specify parallelism or concurrency. One object itself doesn't run until some other object calls its method.
Well you may argue that CORBA programming model can specify the parallelisms by having each components run in parallel. You are right, but the problem of CORBA is, a component only serves request from others. Its working model is request and response, that is, functionality service. You send a request to another component for certain functionality provided by that component. You may wait for the reply from that component. You don't really send your data to that component and then forget them. What passed in CORBA is control, not data. With CORBA, you need reason about how the control flows through all the components, which is ocmpilcated. For parallel applications, you need reason about how multiple controls flow through your components. That's unaccpetable as a desirable parallel programming model.
What we really think is to pass data through components. Each component doesn't need to care about all the control flow interactions with other components, what it cares is what to do when data come and where to pass the result to. So the programming of each component is very simple, just sequential coding.
I found (maybe found by others years ago) that this model of programming (dataflow oriented) is similar to functional programming. In functional programming, the data is passed from function to function without side effects. In dataflow programming, the data is passed from actor (component or task) to actor as well. Funtional programming has neat feature on mathematical properties, so does dataflow programming.
Some people has proved that traditional structural program can be transformed into SSA (single static assignment) form, and SSA is equivalent to functional programming. Here I believe functional programming can be transformed into dataflow programming. That means, traditional structural program can be transformed into dataflow programming. This is nothing new either. The enlightening thing is we can program with dataflow parallel programming, then transform it into parallel structural program that can run well on traditional processor architecture.
Your concern on the communication/synchronization cost of dataflow computation can be solved this way. The performance and programmability are achieved at the same time.