Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 02 Mar 2007 11:36:22 GMT, Dr. Adrian Wrigley wrote:

> On Thu, 01 Mar 2007 14:57:01 +0100, Dmitry A. Kazakov wrote:
> 
>> On Thu, 01 Mar 2007 11:22:32 GMT, Dr. Adrian Wrigley wrote:
>> 
>>> If you don't have multiple processors, lightweight threading is
>>> less attractive than if you do?  Inmos/Occam/Transputer was founded
>>> on the basis that lightweight threading was highly relevant to multiple
>>> processors.
>>> 
>>> Ada has no means of saying "Do these bits concurrently, if you like,
>>> because I don't care what the order of execution is".  And a compiler
>>> can't work it out from the source.  If your CPU has loads of threads,
>>> compiling code with "PAR" style language concurrency is rather useful
>>> and easy.
>> 
>> But par is quite low-level. What would be the semantics of:
>> 
>>    declare
>>       Thing : X;
>>    begin
>>       par
>>          Foo Thing);
>>       and
>>          Bar Thing);
>>       and
>>          Baz Thing);
>>       end par;
>>    end;
> 
> Do Foo, Bar and Baz in any order or concurrently, all accessing Thing.

That's the question. If they just have an arbitrary execution order being
mutually exclusive then the above is a kind of select with anonymous
accepts invoking Foo, Bar, Baz. The semantics is clean.

> Roughly equivalent to doing the same operations in three separate
> tasks.  Thing could be a protected object, if concurrent writes
> are prohibited.  Seems simple enough!

This is a very different variant:

   declare
      Thing : X;
   begin
      declare -- par
         task Alt_1; task Alt_2; task Alt_3;
         task body Alt_1 is
         begin
             Foo (Thing);
         end Alt_1;
         task body Alt_2 is
         begin
             Bar (Thing);
         end Alt_2;
         task body Alt_3 is
         begin
             Baz (Thing);
         end Alt_3;
      begin
         null;
      end; -- par

If par is a sugar for this, then Thing might easily get corrupted. The
problem with such par is that the rules of nesting and visibility for the
statements, which are otherwise safe, become very dangerous in the case of
par.

Another problem is that Thing cannot be a protected object. Clearly Foo,
Bar and Baz resynchronize themselves on Thing after updating its parts. But
the compiler cannot know this. It also does not know that the updates do
not influence each other. It does not know that the state of Thing is
invalid until resynchronization. So it will serialize alternatives on write
access to Thing. (I cannot imagine a use case where Foo, Bar and Baz would
be pure. There seems to always be a shared outcome which would block them.)
Further Thing should be locked for the outer world while Foo, Bar, Baz are
running. So the standard functionality of protected objects looks totally
wrong here.

> I'm looking for something like Cilk, but even the concurrent loop
> (JPR's for I in all 1 .. n loop?) would be a help.

Maybe, just a guess, the functional decomposition rather than statements
could be more appropriate here. The alternatives would access their
arguments by copy-in and resynchronize by copy-out.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de