Category: Source Code

To follow-up with my Parallel For Loops skill sprint last week (lots of good resources there), today I did a deep dive into the Parallel Programming Library (PPL) including Futures, Tasks and custom thread pools.

Here are the slides:

And you can download my Tasks and Futures sample to see how to create, start, check and cancel both Tasks and Futures. Check out the C++ Parallel Examples to see how to use Futures and the PPL in C++.

Until the replay of my Skill Sprint is posted, you can watch this video from Allen Bauer covering the Parallel Programming Library Architecture from CodeRage 9.

Be sure to sign up for and check out the other Skill Sprints.

This is some code I wrote a long time ago as part of the TDAG mailing list. It calculates Factorials, the number of Combinations and Permutations. This is the mathematics, it calculates the number of Combinations and Permutations, it doesn’t create each different Combination and Permutation.

They take Cardinals as parameters because it doesn’t make sense to accept negative numbers. Keep in mind that factorials get big really, really quickly, so if you use too large of numbers then it will overflow even the Int64.

unit FactCombPerm;

interface

// Parameters are Cardinal because Int64 isn't Ordinal
//  Besides, Factorial(100) will overflow Int64 already.
function Factorial(const ANumber: Cardinal): Int64; overload;
function Factorial(const ANumber: Cardinal;
                   const AStop: Cardinal): Int64; overload;
function CombinationUnOpt(const ACount, AChoose: Cardinal): Int64;
function Combination(const ACount, AChoose: Cardinal): Int64;
function Permutation(const ACount, AChoose: Cardinal): Int64;

implementation

function Factorial(const ANumber: Cardinal): Int64; overload;
// n! = n * (n-1) . . . n(2)
var
  lCtr: Cardinal;
begin
  Result := 1;
  for lCtr := ANumber downto 2 do
    Result := Result * lCtr;
end;

function Factorial(const ANumber: Cardinal;
                   const AStop: Cardinal): Int64; overload;
// Factorial with a stop point (needed in the optimized Combination routine
// if no AStop is specified then is the same as Factorial
var
  lCtr: Cardinal;
begin
  Result := 1;
  if ANumber >= AStop then
    for lCtr := ANumber downto AStop do
      Result := Result * lCtr;
end;

function CombinationUnOpt(const ACount, AChoose: Cardinal): Int64;
// n!
// n_C_k = ----------
// k!(n - k)!
begin
  if AChoose < ACount then
    Result := Factorial(ACount)
      div (Factorial(AChoose) * Factorial(ACount - AChoose))
  else
    Result := 0;
end;

function Combination(const ACount, AChoose: Cardinal): Int64;
// n!
// n_C_k = ----------
// k!(n - k)!
// with optimizations even!
begin
  if AChoose < ACount then
    Result := Factorial(ACount, succ(ACount - AChoose))
      div (Factorial(AChoose))
  else
    Result := 0;
end;

function Permutation(const ACount, AChoose: Cardinal): Int64;
// n!
// n_P_k = --------
// (n - k)!
begin
  if AChoose < ACount then
    Result := Factorial(ACount)
      div Factorial(ACount - AChoose)
  else
    Result := 0;
end;

end.

My original optimization had a bug in it, but Bryan Mayland fixed it for me. This is old code, and there are probably some options to optimize it better. I’d love input, suggestions, etc.

Have you ever had some code you wanted to run outside of the event handler that causes the code to run? If not, then this blog post isn’t for you. I’m not here to debate why you would want to do that, or if it is a good idea or not. I just know there’ve been times I’ve needed my code to run outside the event handler, or just a bit later.

One use case example: You are calling a slow routine (Network I/O maybe) and don’t want to freeze the UI while you wait for it to execute.

Still with me? Good. What I used to do was drop a TTimer on the form and set the Interval to 1, then enable it to trigger the code to run later. This worked, but it was messy. You had a timer to deal with, and you had to remember to disable it in the event handler, so it didn’t run multiple times. You also could have used a TThread, which may have been a better solution, but still seemed kind of messy, especially if you wanted to update the UI from your code.

Thanks to the new System.Threading library introduced with XE7, I’ve created a simple procedure that makes this a breeze to do. I call the procedure NonBlocking, but you could just as easily call it RunALittleLater, RunOutsideHandler, etc.

uses System.Threading;

procedure NonBlocking(const Proc: TThreadProcedure);
begin
  TTask.Create(procedure begin
    TThread.Queue(nil, Proc);
  end).Start;
end;

All this does is create a task, and then inside the task queue an update back to the main thread to execute the code that is passed to this procedure as an anonymous method. You could easily just write this code inline, but I thought it worthwhile creating a procedure to handle it for me.

Lets look at a normal execution scenario:

  //...
  ListBox1.Items.Add('Before Handler');
  EventHandler;
  ListBox1.Items.Add('After Handler');
  //....

procedure TForm1.EventHandler;
begin
  ListBox1.Items.Add('Inside Handler');
end;

When this is run, our ListBox1 will look like

• Before Handler
• Inside Handler
• After Handler

which is what we would expect. Now when we introduce a call to our new procedure in the EventHandler:

  //...
  ListBox1.Items.Add('Before Handler');
  EventHandler;
  ListBox1.Items.Add('After Handler');
  //....

procedure TForm1.EventHandler;
begin
  ListBox1.Items.Add('Inside Handler 1');
  NonBlocking(procedure begin
    ListBox1.Items.Add('Outside Handler'); // This will run last
  end);
  ListBox1.Items.Add('Inside Handler 2');
end;

Our ListBox1 will look like

• Before Handler
• Inside Handler 1
• Inside Handler 2
• After Handler
• Outside Handler

Notice that Outside Handler was the very last line added, even though it is written between Inside Handler 1 and Inside Handler 2. It even occurs after the After Handler line. Also, this works across all platforms: iOS, Android, Windows and OS X.

Everything before and within the call to NonBlocking will execute in order, but the code within NonBlocking will execute after the code that comes after that anonymous method.

If you have a ShowMessage or something else that blocks the UI thread in the event handler, then the code you passed to the NonBlocking procedure will be executed early, which is fine since the UI thread was already blocked.