Below an elaboration on my answer to the question [WayBack] I don’t understand the following part of the second Delphi example:TThread.Synchronize… – Alberto Paganini – Google+:
I was looking at the Task example at the EMB wiki link below
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Tutorial:_Using_Tasks_from_the_Parallel_Programming_Library
and I don’t understand the following part of the second Delphi example:
TThread.Synchronize(nil,
procedure
begin
Label1.Text := lValue.ToString;
end);
why is there the need to pass Label1.Text := lValue.ToString;
as procedure
in TThread.Synchronize
?
Why not a simple Label1.Text := lValue.ToString;
?
Basically that question can be either of these:
- Why is there no easier language construct than wrapping the callback in a
procedure
(anonymous method).
- Why a call to
TThread.Synchronize
at all?
The tutorial that Alberto refers to is [WayBack] Tutorial: Using Tasks from the Parallel Programming Library – RAD Studio. That example uses the TTask
feature in Delphi, but the portion he has a question about is general to any multi-treading in Delphi that touches the updating of a VCL or FMX UI from another thread.
This is the more complete code in the meant example:
procedure TForm1.ButtonTask1Click(Sender: TObject);
var
lValue: Integer;
begin
Label1.Text := '--';
TTask.Run(procedure
begin
{Some calculation that takes time}
Sleep(3000);
lValue := Random(10);
TThread.Synchronize(nil,
procedure
begin
Label1.Text := lValue.ToString;
end);
end);
end;
What happens here is that the TTask
is used to run some code (starting with {Some calculation that takes time}
) in a different thread (that is being determined by the framework behind TTask
).
I recommend against using TTask
(or any other part of the Delphi Parallel Programming Library) as I agree with Stefan Glienke in [WayBack] Hello, Do you know why the “default” keyword of a class property is sometime defined also as an attribute ? – Paul TOTH – Google+:
If that works as well as the PPL does I would not touch it with a 10 foot pole ;)
With “that”, he refers to the APL (Asynchronous Programming Library [Archive.is]) which got introduced in Delphi XE8 and adds asynchronous support for UI controls, but unlike .NET (which implements it on the .NET TControl
equivalent) shifted it down to TComponent
probably because that’s the common ancestor for both VCL and FMX. But that’s a topic for another day.
The Delphi Parallel Programming Library (DPL) is a complex and intricate framework originally started as Delphi Parallel Library (DPL) and modelled after [WayBack] Intel’s Threading Building Blocks (TBB) and Microsoft’s Task Parallel Library (TPL) (not in WayBack, but moved to the CHM file [WayBack], see also[WayBack] Task Parallel Library changes since the MSDN Magazine article | Parallel Programming with .NET)
Most parts of the DPL were written over at least 7 years time by former Chief Scientist Allen Bauer and introduced in Delphi XE7 as the Delphi Parallel Programming Library (PPL), see [WayBack] Delphi Parallel Programming Library & Memory Managers – Steve Maughan and [WayBack] The Oracle at Delphi: Lock my Object… Please!.
Since Delphi XE7, the PPL hardly got maintenance and now most if not all of the people having knowledge about it have left Embarcadero: early 2016, [Archive.is] Delphi Chief Scientist Allen Bauer Has Left Embarcadero/Idera | Hacker News leaving a big gap as “There are no plans that I’m aware of to move someone into my old position… All those that I would consider qualified are either already gone or are currently looking elsewhere.” (it is not in the [WayBack] part of How safe is Delphis future? Who is the new Lead Compiler Engineer? Who is the new Chief Scientist? – Ralf Stocker – Google+, hence the screen shot).
Luckily, Allen copied most of his old Embarcadero blog over to his personal one (including comments!), so there is quite some historic reference, see for instance [WayBack] Thread pools <> Task handling. – Community Blogs – Embarcadero Community and [WayBack] The Oracle at Delphi: Thread pools <> Task handling.
So back ensuring you can execute some code on the main thread and the questions from the G+ post:
- Why is there no easier language construct than wrapping the callback in a
procedure
(anonymous method).
- Why a call to
TThread.Synchronize
at all?
Lets start with the questions in order I answered them, starting with the my response:
Read the rest of this entry »