Hello,

After the couple of questions I had about reference counting and cmpxchg, I can finally share what we have been working on, this would be the eternal gratitude part. A freepascal implementation of active objects.

http://werner.yellowcouch.org/Papers/activeobjects/index.html

From the abstract: Active objects seperates various tasks through means of a message queue whereby the queue will activate the underlying task whenever a new message comes in. Using this abstraction it becomes possible to have time speration between threads (they will not influence each others execution/not wait for each other), space separation (different tasks will not write into each others data space), scheduling independence (we can run multiple tasks with one, two or more processes), syntactical separation (each task is declared in its own source file) and finally lockfree programming, which thus also leads to a noticable lack of deadlock and race-conditions

The library consists of a precompiler and a runtime. Originally, both were written in C++. Recently I modified the compiler to generate pascal code. In general, to write an active object description one writes a littl file:

active DemoSender
{
  integer tosend = 20;
  DemoReceiver recv;
  message startSending(DemoReceiver vrecv, integer nr);
};
active DemoReceiver
{
  message printNumber(integer nr);
};

This can then be compiled to a forward include, an interface include and an implementation include.-

aoc demo2.ao demo2.pas --pascal

This generates

- demo2_ifc.inc: contains the most important part of the interface section. It can be included in other interface sections.
- demo2_imp.inc: contains all the function, constructor and producedure implementations. Can be included in -guess what- an implementation section.
- demo2_fwd.inc: if you need them, you get a collection of forward declarations. Can also be included in an interface section.

Of course, the messages startSending and printNumber must be implemented. This is done in the file demo2.pas

program demo2;
{$MODE OBJFPC}{$H+}
uses cthreads, sysutils, active_objects;
{$include demo2_fwd.inc}
{$include demo2_ifc.inc}
{$include demo2_imp.inc}
Function ActiveDemoSender.startSending(vrecv: DemoReceiver; nr:
Integer): ElementResult;
Var
   i : integer;
Begin
   WriteLn(-14);
   tosend:= nr;
   for i := 0 to tosend-1 do vrecv.printNumber(i);
   deactivate;
   Result:= Done;
   WriteLn(-15);
End;
Function ActiveDemoReceiver.printNumber(nr: Integer): elementResult;
Begin
   WriteLn(nr);
   if nr = 20 then deactivate;
   Result:= Done;
End;

An then of course, in the end, we want to start these two task after allocating them-

Var
   sender : DemoSender;
   recv      : DemoReceiver;
begin
   sender:= DemoSender.Create;
   recv:= DemoReceiver.Create;
   WriteLn('Loaded Objects. Press enter...');
   Readln();
   sender.startSending(recv,100);
   sleep(100);
End.

So, obviously a very quick example. If you are interested, it is probably best to read the article mentioned above and to download both the C++ version (it contains the compiler) and the fpc version (which contains the runtime) from

ftp://ftp.yellowcouch.org/flow/

With kind regards,

Hello,

This looks promising.

Can you explain the similarities and differences with MPI ?

Several people have asked about MPI in Free Pascal. Maybe this is an answer for them.

Michael.

Michael Van Canneyt wrote

Hello, This looks promising. Can you explain the similarities and differences with MPI ?

That would require me to read up on what MPI is and honoustly, I'm not a big fan on doing that, certainly not after I went to their homepage and saw around 70 lines of contributing companies, all of them big names.

If my guess is correct, MPI is similar to a CORBA IDL Specification (in general terms). If this undertsanding is correct then MPI has nothing to do with the Acrtive Objects as I present them. E.g: the active objects library cannot perform interprocess communication and certainly not accross different machines. It only deals with thread activation and deactivation at appropriate times. To do so, it uses a queue in which a normal stackframe is pushed and at a later time executed.

Several people have asked about MPI in Free Pascal. Maybe this is an answer for them.

People hoping that this is an MPI (in the sense of http://www.mcs.anl.gov/research/projects/mpi/) for pascal will be disappointed. Those who are looking for an alternative to thread based approaches to deal with multiple tasks in a single program might find this interesting.

Wkr,

MPI is for passing messages between parallel running tasks. (the name means Message Passing Interface)
This is what Active Objects does.

To me, the difference seems that Active Objects runs within a single process, and MPI allows to run the tasks in different processes, even on different machines.

It seems to me that there are more parallels between MPI and Active Objects than you think. Both are tools for parallel (sic) computing, after all.

Michael.

That is correct. The active objects can run multple tasks with a choosen number of threads, all within the same process. By default, each active object has its own associated thread.

MPI on the other hand can send messages accross multiple machines and processes. This requires either a shared memory or a serialization layer, neither of which I looked into.

Historically, the main reason I wrote this was because the thread management in BpmDj (http://bpmdj.yellowcouch.org/) had become a nightmare and the only sensible way to deal with this was thinking in terms of message queues. Implementing that however was remarkably hard. Especially the fairness requirement was hard to solve. E.g: 1000 tasks sending messages to 1 task should not keep that one task from performing work.

It seems to me that there are more parallels between MPI and Active Objects than you think. Both are tools for parallel (sic) computing, after all.

Well, I would say: give it a try. If somebody feels it would be useful to extend it accross process by adding an extra new class that would serialize a message before sending it to a target, that would be interesting. However, in that case, we must think about passing a local stub through a message to a remote active object. That would require the serializer to deseriealize this 'local stub' to either the local active object or to a new stub that connects to the originally intended remote active object. So, this will heavily depend on the serialisation and deserialisation capabilities of fpc. And of course, I have no experience with that as such.

Wkr,