[fpc-devel] Russian locale information not compatible with FPClocale variables

["Vinzent Höfler"]

[...]
> Because it's so simple we could then announce that we support
> parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did
> come along eg in Delphi or some other of the languages mentioned, we
> could take a view as to whether we'd support it. 

Sorry, but adding parallelism into the language without providing proper synchronization primitives sounds kind of stupid to me.

But to add some more food to the discussion: For "asynchronous" or something similar I would require it to be scoped:

procedure RunningMultiCore;
   procedure Task1; asynchronous; begin ... end;
   procedure Task2; asynchronous; begin ... end;
var
   i : Integer;
begin
   begin // Task scope
      Task1;

      for i := 1 to 1000 do
         Task2;
   end; // If we get here, Task1 and 1000 Task2's are finished.

   // Evaluate results...
end;

Alas, there's no way to declare sort of block-local variables... but this at least allows for finer grained parallelism without to many hassles (when and where to decide of some routine has finished, was it started at all before and such things). Coarse grain parallelism could be handled the usual way via TThread class & Co.

Of course, there's the problem with core-utilization (how many subroutines are allowed to run parallel? etc.pp.), but as those are mostly runtime decisions, there should either be some API to control the behaviour or the compiler/OS should decide as they seem fit. And the main problem: To evaluate any results, you need some memory being accessed by the parallel tasks, which brings us back to the initial objection: There's no sense in doing that without also providing proper synchronization primitives. "volatile" or "atomic" keyword, anyone?
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196