I need a function that will use my cpu 100% . I have a single core cpu any ideas ?
Does the thread need to be set in high priority ?
A loop (infinite) usually does the job fine:
while true do begin
end;
Obviously forcing the CPU go to 100% without doing anything useful should be done only for academic purposes and on your own hardware and never in any real application that you intend to ship.
For example, by the next thread:
unit Unit2;
interface
uses
Classes;
type
TLoadThread = class(TThread)
public
class var Stop: Boolean;
protected
procedure Execute; override;
public
constructor Create;
end;
implementation
constructor TLoadThread.Create;
begin
inherited Create;
FreeOnTerminate:= True;
end;
procedure TLoadThread.Execute;
begin
repeat until Stop;
end;
end.
A usage example:
type
TForm1 = class(TForm)
Button1: TButton;
Button2: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
end;
var
Form1: TForm1;
implementation
uses Unit2;
{$R *.dfm}
procedure LoadCPU;
begin
TLoadThread.Stop:= False;
TLoadThread.Create;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
LoadCPU;
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
TLoadThread.Stop:= True;
end;
if your CPU has N cores, click Button1 N times to reach 100% CPU load; no need to increase thread priority.
Related
I created two WndProcs in the main thread and then I post a messages from other threads to each of them, almost at the same time, but starting with WndProc1. This WndProc1 has a job to do which lasts for some time... It sigals when it begins and when it ends. WndProc2 also signal when is accessed. Now, when I press the button to start this test, I get: "P1-Enter ... [delay] ... P1-Leave WndProc2". As you can see, the second message waits for WndProc1 to finish, although he was sent to to WndProc2 ! What I want to know is how this serialization works if those two WndProcs have nothing in common ? I think that even happens if I have two different components, each with his own WndProc (but I didn't check).
unit Unit1;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, SyncObjs;
type
TMyThread = class(TThread)
private
FHnd: HWND;
FTime: Integer;
protected
procedure Execute; override;
public
constructor Create(AHnd: HWND; ATime: Integer);
end;
TForm1 = class(TForm)
Button1: TButton;
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
private
TestHand1, TestHand2: HWND;
MyT1, MyT2: TMyThread;
protected
procedure TestWndProc1(var Msg: TMessage);
procedure TestWndProc2(var Msg: TMessage);
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
constructor TMyThread.Create(AHnd: HWND; ATime: Integer);
begin
inherited Create;
FHnd:= AHnd;
FTime:= ATime;
end;
procedure TMyThread.Execute;
begin
Sleep(FTime);
PostMessage(FHnd, WM_USER, 0, 0);
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
TestHand1:= AllocateHWnd(TestWndProc1);
TestHand2:= AllocateHWnd(TestWndProc2);
end;
procedure TForm1.TestWndProc1(var Msg: TMessage);
var I: Integer;
A, B, C: Cardinal;
begin
if Msg.Msg = WM_USER then begin
Caption:= Caption + ' P1-Enter';
A:= $12345678; B:= $98765432;
for I:= 1 to 180000000 do begin
C:= A * B; B:= C * A; A:= B * C;
end;
Caption:= Caption + ' P1-Leave';
end;
end;
procedure TForm1.TestWndProc2(var Msg: TMessage);
begin
if Msg.Msg = WM_USER then
Caption:= Caption + ' WndProc2';
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
Caption:= '';
MyT1:= TMyThread.Create(TestHand1, 300);
MyT2:= TMyThread.Create(TestHand2, 350);
end;
end.
What you see is perfectly expected. Each thread has one and only one message queue and may have zero to many window handles. Window handles usually correspond to visual components but not necessarily as in your example.
Somewhere in the code (for a GUI in Delphi, this is in the Forms unit), there is a so called "message loop" which retrieves messages from the queue and dispatches them to the corresponding WndProc. The dispatch mechanism is like a simple function call: it is blocking while a message is being processed, unless the message handler calls the message pump again (where reentrancy problems start, if not handled correctly). Look at the documentation and look in the Forms unit for TApplication.ProcessMessages and in the Classes unit for AllocateHWnd/DeallocateHWnd.
If you want to execute code in parallel you must create separate threads; each one will execute in parallel as long as there are fewer threads than CPU cores and threads are not blocked by I/O or mutexes, semaphores and critical sections. If too many threads are ready to execute they are scheduled using preemptive multitasking.
You can communicate between threads using messages. For that, a thread must create a window handle and have a message pump.
In Delphi, the GUI can only be accessed from the main thread. If a secondary thread has something to display then it must let the display code execute by the main thread, most likely again through a message between the secondary/worker thread and main thread, or use the Synchronize method, or use other communication mechanisms such as pipes, sockets, file I/O, shared memory. Alone or in combination.
So I came across some code similar to this:
aThread := TmyThread.Create(param1, param2);
h := aThread.handle;
repeat
if (MsgWaitForMultipleObjects(1, h, False, INFINITE, QS_ALLINPUT) = WAIT_OBJECT_0)
then break;
Application.ProcessMessages
until False;
aThread.Free;
myProgressBar.Progress := myProgressBar.Max; //an internal component, not really important here
Which, I assume, is meant to provide a way of updating the GUI so it doesn't appear blocked, but also allow for the end process GUI to be updated (the progress bar), while some long task is taking place.
But it contains the dreaded Application.ProcessMessages.
I've read The Darkside of Application.ProcessMessages and many other Delphi blogs suggesting it's time to use a new thread instead when Application.ProcessMessages is being used.
So, is it wise to phase out this method of keeping the main/GUI threaded idle for something like the AnonymousThread approach shown here? Or something else?
This Noob is confused as to why it's suggested that a process that calls Application.ProcessMessages is a good candidate for a Thread, but the thread in question relies on the very thing we're being told not to do!
The main idea is not to wait for the thread. Thread should inform your form when it finished. In other words the code which should be executed after the the thread is finished should be isolated to a separate procedure (see TForm1.ThreadCompletedHandler) and thread should call it after it is finished.
Here is a small sample:
unit Unit1;
interface
uses
Winapi.Windows, Winapi.Messages,
System.SysUtils, System.Variants, System.Classes,
Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ComCtrls;
type
TmyThread = class(TThread)
private
FParam1, FParam2: Integer;
FUpdateProc: TProc<TmyThread, Integer>;
FCompleteProc: TProc<TmyThread>;
procedure SyncCompleteProc;
procedure QueueUpdateProc(APosition: Integer);
protected
procedure Execute; override;
public
constructor Create(AParam1, AParam2: Integer;
AUpdateProc: TProc<TmyThread, Integer>;
ACompleteProc: TProc<TmyThread>);
end;
TForm1 = class(TForm)
Button1: TButton;
myProgressBar: TProgressBar;
procedure Button1Click(Sender: TObject);
private
FThread: TThread;
procedure ThreadUpdateHandler(AThread: TMyThread; APosition: Integer);
procedure ThreadCompletedHandler(AThread: TMyThread);
protected
procedure UpdateActions; override;
public
destructor Destroy; override;
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
{ TmyThread }
constructor TmyThread.Create(AParam1, AParam2: Integer; AUpdateProc: TProc<TMyThread, Integer>;
ACompleteProc: TProc<TMyThread>);
begin
FParam1 := AParam1;
FParam2 := AParam2;
FUpdateProc := AUpdateProc;
FCompleteProc := ACompleteProc;
inherited Create(False);
end;
procedure TmyThread.Execute;
var
I: Integer;
begin
//inherited; - abstract
try
I := FParam1;
while not Terminated and (I < FParam2) do
begin
Sleep(1000);
Inc(I);
QueueUpdateProc(I);
end;
finally
if Assigned(FCompleteProc) then
TThread.Queue(Self, SyncCompleteProc);
end;
end;
procedure TmyThread.QueueUpdateProc(APosition: Integer);
begin
if Terminated or not Assigned(FUpdateProc) then
Exit;
TThread.Queue(Self,
procedure
begin
FUpdateProc(Self, APosition);
end);
end;
procedure TmyThread.SyncCompleteProc;
begin
FCompleteProc(Self);
end;
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
const
param1 = 1;
param2 = 5;
begin
myProgressBar.Min := param1;
myProgressBar.Max := param2 + 1;
myProgressBar.Position := param1;
FThread := TmyThread.Create(param1, param2, ThreadUpdateHandler, ThreadCompletedHandler);
end;
destructor TForm1.Destroy;
begin
if Assigned(FThread) then
FThread.Terminate;
inherited;
end;
procedure TForm1.ThreadCompletedHandler(AThread: TmyThread);
begin
try
if not AThread.Terminated then // check form is not destroye yet
begin
FThread := nil;
myProgressBar.Position := myProgressBar.Max; //an internal component, not really important}
end;
finally
FreeAndNil(AThread);
end;
end;
procedure TForm1.ThreadUpdateHandler(AThread: TMyThread; APosition: Integer);
begin
if not AThread.Terminated then // check form is not destroye yet
myProgressBar.Position := APosition;
end;
procedure TForm1.UpdateActions;
begin
inherited;
Button1.Enabled := not Assigned(FThread);
end;
end.
and DFM file
object Form1: TForm1
Left = 0
Top = 0
Caption = 'Form1'
ClientHeight = 290
ClientWidth = 554
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -11
Font.Name = 'Tahoma'
Font.Style = []
OldCreateOrder = False
PixelsPerInch = 96
TextHeight = 13
object Button1: TButton
Left = 24
Top = 16
Width = 75
Height = 25
Caption = 'Button1'
TabOrder = 0
OnClick = Button1Click
end
object myProgressBar: TProgressBar
Left = 120
Top = 108
Width = 150
Height = 17
TabOrder = 1
end
end
NB In this sample form does not wait for the thread so potentially we may close the application before the thread is terminated. It should not be a problem for this sample as it simple enough but in real live you may need to wait for the thread in Form.Destroy or create some thread manager which should wait for all running threads before application is finished.
I am trying to write a Delphi code to update the TImage components on a from. I was using C++ for long time but don't have much experience in Delphi;however, I need to use Delphi for some reason. I obtained and modified a similar code to do the task as shown as follows. I have 4 TImages components placed on a form, I start a thread to update the images when the player press the button. I have 6 resource bitmaps with numbered in 1 to 6 embedded in the project and the code will randomly pick and load the resource bitmap into the TImage. I find that using the thread sometimes, some images will not be drawn (just blank like no image being loaded). I know you may be wondering why I need to use a thread and why not just call ShowRanodmImage when the button is pressed. In this simple case, surely I don't have to use thread instead but I am going to apply to some situation that threading must be used. So my question is why the following code will occationally not show the proper image? How to fix that? Thanks a lot.
unit TTUnit;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls;
type
TTestThread = class;
TTestForm = class(TForm)
NextBTN: TButton;
P11: TPanel;
P12: TPanel;
P13: TPanel;
P14: TPanel;
CELL11: TImage;
CELL12: TImage;
CELL22: TImage;
CELL21: TImage;
procedure FormCreate(Sender: TObject);
procedure NextBTNClick(Sender: TObject);
private
myThread :TTestThread;
pImgs: array[1..2, 1..2] of TImage;
public
procedure ShowRandomImg;
end;
TTestThread = class(TThread)
private
myForm :TTestForm;
protected
procedure Execute(); override;
public
constructor Create(aFrom :TTestForm; CreateSuspended: Boolean);
end;
var
TestForm: TTestForm;
implementation
{$R *.dfm}
procedure TTestForm.FormCreate(Sender: TObject);
begin
myThread := TTestThread.Create(Self, True);
pImgs[1][1]:=CELL11; pImgs[1][2]:=CELL12;
pImgs[2][1]:=CELL21; pImgs[2][2]:=CELL22;
end;
procedure TTestForm.NextBTNClick(Sender: TObject);
begin
myThread.Resume;
end;
procedure TTestForm.ShowRandomImg;
var
i, j :Integer;
r :array[1..2, 1..2] of Integer;
begin
Self.NextBTN.Enabled := false;
r[1][1] := Random(6)+1;
r[1][2] := Random(6)+1;
r[2][1] := Random(6)+1;
r[2][2] := Random(6)+1;
for i := 1 to 2 do
begin
for j := 1 to 2 do
begin
pImgs[i][j].Picture.Bitmap.LoadFromResourceID(HInstance, r[i][j]);
pImgs[i][j].Canvas.Font.Size := 38;
pImgs[i][j].Canvas.Font.Color := clRed;
pImgs[i][j].Canvas.Font.Style := [fsBold];
pImgs[i][j].Canvas.TextOut(20, 20, inttostr(r[i][j]));
end;
end;
Self.NextBTN.Enabled := true;
end;
////////////////////
constructor TTestThread.Create(aFrom: TTestForm; CreateSuspended: Boolean);
begin
inherited Create(CreateSuspended);
Self.myForm := aFrom;
end;
procedure TTestThread.Execute;
begin
inherited;
Repeat
Self.myForm.ShowRandomImg;
Self.Suspend;
Until Terminated;
end;
end.
I'm trying to build a generic worker thread in Delphi, one that I can pass a function/procedure (doesn't matter) as an argument and let it execute.
My guess is to add a field in the TThread class and call it from TThread.Execute.
So the code outside the thread is gonna be:
MyThread := TWorkerThread.Create(True);
Mythread.CallBackF := #Foo;
try
MyThread.Resume;
except
MyThread.Free;
end;
How do I keep a reference of #foo in the TWorkerThread and call it from inside Execute?
Also, a good start into using generic threads would be AsyncCalls or Omni Thread Library.
I do not pretend to be an expert on threading, but I think this will do it:
interface
type
TProcRef = reference to procedure;
TWorkerThread = class(TThread)
public
proc: TProcRef;
procedure Execute; override;
class procedure RunInThread(AProc: TProcRef);
end;
implementation
procedure TWorkerThread.Execute;
begin
inherited;
proc;
end;
class procedure TWorkerThread.RunInThread(AProc: TProcRef);
begin
with TWorkerThread.Create(true) do
begin
FreeOnTerminate := true;
proc := AProc;
Resume;
end;
end;
Then, if you got any procedure, like
procedure P;
begin
while true do
begin
sleep(1000);
beep;
end;
end;
you can just do
procedure TForm1.Button1Click(Sender: TObject);
begin
TWorkerThread.RunInThread(P);
end;
You can even do
TWorkerThread.RunInThread(procedure begin while true do begin sleep(1000); beep; end; end);
Take a look at QueueUserWorkItem function.
It executes arbitrary function in a thread, without requiring you to create one.
Just don't forget to switch IsMultithreaded global variable to True.
I'm user of delphi 2010, my current machine is intel core i7, running windows 7 x64. I've write the following codes:
type
TForm1 = class(TForm)
Memo1: TMemo;
Button1: TButton;
Button2: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
private
FCount: Integer;
FTickCount: Cardinal;
procedure DoTest;
procedure OnTerminate(Sender: TObject);
end;
TMyThread = class(TThread)
private
FMethod: TProc;
protected
procedure Execute; override;
public
constructor Create(const aCreateSuspended: Boolean; const aMethod: TProc);
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var i: integer;
T1, T2: Cardinal;
begin
T1 := GetTickCount;
for i := 0 to 9 do
DoTest;
T2 := GetTickCount;
Memo1.Lines.Add(Format('no thread=%4f', [(T2 - T1)/1000]));
end;
procedure TForm1.Button2Click(Sender: TObject);
var T: TMyThread;
i: integer;
begin
FCount := 0;
FTickCount := GetTickCount;
for i := 0 to 9 do begin
T := TMyThread.Create(True, DoTest);
T.OnTerminate := OnTerminate;
T.Priority := tpTimeCritical;
if SetThreadAffinityMask(T.Handle, 1 shl (i mod 8)) = 0 then
raise Exception.Create(IntToStr(GetLastError));
Inc(FCount);
T.Start;
end;
end;
procedure TForm1.DoTest;
var i: integer;
begin
for i := 1 to 10000000 do
IntToStr(i);
end;
procedure TForm1.OnTerminate(Sender: TObject);
begin
Dec(FCount);
if FCount = 0 then
Memo1.Lines.Add(Format('thread=%4f', [(GetTickCount - FTickCount)/1000]));
end;
constructor TMyThread.Create(const aCreateSuspended: Boolean; const aMethod:
TProc);
begin
inherited Create(aCreateSuspended);
FMethod := aMethod;
FreeOnTerminate := True;
end;
procedure TMyThread.Execute;
begin
FMethod;
end;
Click on Button1 will shows 12.25 seconds, while Button2 will shows 12.14 seconds. My problem is why i cannot get more obvious difference of time taken (less than 10 seconds) although i'm running parallel threads ?
Memory allocation seems to be the main problem here.
If you replace the payload with
procedure TForm6.DoTest;
var i: integer;
a: double;
begin
a := 0;
for i := 1 to 10000000 do
a := Cos(a);
end;
the code will parallelize nicely indicating that there's no real problem with your framework.
If you, however, replace the payload with memory allocation/deallocation
procedure TForm6.DoTest;
var i: integer;
p: pointer;
begin
for i := 1 to 10000000 do begin
GetMem(p, 10);
FreeMem(p);
end;
end;
the parallel version will run much slower than the single-threaded one.
When calling IntToStr, a temporary string is allocated and destroyed and this allocations/deallocations are creating the bottleneck.
BTW1: Unless you really really know what you're doing, I'm strongly advising against running threads at tpTimeCritical priority. Even if you really really know what you're doing you shouldn't be doing that.
BTW2: Unless you really really know what you're doing, you should not mess with affinity masks on thread level. System is smart enough to schedule threads nicely.
If you have memory intensive threads (many memory allocations/deallocations) you better use TopMM instead of FastMM: http://www.topsoftwaresite.nl/
FastMM uses a lock which blocks all other threads, TopMM does not so it scales much better on multi cores/cpus!
I'm not 100% sure, but there's a chance that the OnTerminate event is called from the context of the TThread. If that's the case (I must admit I haven't checked this), you'd be better off using InterlockedDecrement on FCount, and synchronizing the GUI updates. Just a minor point, but in production code these things matter.