Synchronous class for concurrent programming

Label: ♦english ♦feature planning

[514] Synchronous class for concurrent programming

fu created at Wednesday, 2010-12-22, 08:36:32

24 Replies, 6514 Hits

These days I have been thinking the possibility to bring back the previous features: Asynchronous Function Call (AFC) and Message Passing Interface (MPI), but not in the same way, instead a much simpler way. The original design of MPI attempted to unify concurrent and distributed computation model under single framework, which was a bit too ambitious, and is hard to implement consistently across different platforms. Additionally, the original design of AFC and MPI does not pay much consideration to consistency of shared data. To address such problems, I have come up with a new design that should be much easier to implement and simpler to use.

The basic idea is to support a specialized class (for the moment, let's call such class as Synchronous Class and its instance object as Synchronous Object), possibly by specifying a special attribute in the class definition or prefix the class name with certain special symbol (or by some other way) as the following:

class [synchronous] SynObject { ... }
# or
class @SynObject { ... }

Such class will have the following properties:

All its member variables are private or protected;
All its public methods are asynchronous methods, namely, when one such method is called, the control will be returned immediately to its caller, and this method might be executed immediately and concurrently with its caller, or might be caller at a later time.
All its private or protected methods are normal methods;
Only simple data types and synchronous objects can be passed across the function call boundary (parameters and returned value) of public methods.

Under the Actor Model, the instance object of such class is essentially an actor, and calling to its public method is essentially equivalent to sending the object a message. Moreover, different objects/actors can handle their messages concurrently, and each object only handles one message at one time. With all these properties, data consistency can be guaranteed by the fact that only synchronous objects can be used as shared data, and the modification to its internal data has to be done through its public methods, whose execution model will guarantee its data will not be accessed by multiple competing threads at the same time.

The calling to a public method of synchronous objects will return a future value. Retrieving value from such future value object will cause the caller to block until the value becomes available when the method has finished execution.

Just as a simple example,

class @Counter
{
  var count = 0;

  public
  routine Increase(){ count += 1 }
  routine Decrease(){ count += 1 }
}
class @Consumer
{
  public
  routine Update( counter : Counter ){
    for( i = 1 : 100 ) counter.Increase();
  }
}
counter = Counter();
c1= Consumer();
c2= Consumer();
fv1 = c1.Update( counter );
fv2 = c2.Update( counter );
fv1.value(); # block until c1.Update( counter ) is done
fv2.value(); # block until c2.Update( counter ) is done

Because of the requirement on the type of data that are allowed to be passed across the function call boundary, there is clear restrictions on the types of parallel computation that can be implemented by the concurrent model in this proposal. So I am not very sure if a feature based on this proposal can be of general interest to many people. Some feedbacks might help, and are extremely welcome.

Comments

Change picture: