[...]
> 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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
