A thread fails to update the image as expected - multithreading

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.

Related

Better methodology for indicating thread finished than MsgWaitForMultipleObjects?

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.

Delphi EOutOfResources Screen Capturing

The program which is giving this error. Sometimes immediately, sometimes after a short time
http://www1.datafilehost.com/d/39f524c0 Thread Suspends in some try finally block
Source:
http://www1.datafilehost.com/d/1cae7b24 EOufOfResources During debugging
Im sorry for bad English. I have the following problem: I try to do 5 fps screenshots and draw the cursor icon on them, recode BMP in PNG and send it over the network through blocking sockets Indy. After sending a screenshot proportionally compressed and placed on TImage (desktopimage) on the main form. If I'm doing all this in a timer - that everything works fine if I am doing all of this code in Synchronize() it also works fine, but it causes freezing of the interface, I want to get rid of it, and doing so in PNG compression in the thread, now I tried to break several Synchronize() to find the error (I get an error EOutOfResources), but I could not. Please help. Here is my code:
TCaptureThread = class(TThread)
private
bmp: TBitmap;
DC: HDC;
h:hwnd;
thumbRect : TRect;
maxWidth, maxHeight:integer;
png:TPNGImage;
Stream:TMemoryStream;
RecBlock:TCommBlock;
r: TRect;
CI: TCursorInfo;
Icon: TIcon;
II: TIconInfo;
commblock:TCommblock;
procedure showthumb;
procedure send;
procedure stretch;
procedure getscreen;
procedure fixsize;
protected
procedure Execute; override;
constructor Create(CreateSuspended: Boolean);
destructor destroy; override;
end;
constructor TCaptureThread.Create(CreateSuspended: Boolean);
begin
bmp:=TBitmap.Create;
Stream:=TMemoryStream.Create;
png:=TPNGImage.Create;
Icon := TIcon.Create;
inherited Create(CreateSuspended);
end;
destructor TCaptureThread.destroy;
begin
png.Free;
bmp.Free;
Icon.Free;
stream.Free;
inherited;
end;
procedure TCaptureThread.Execute;
begin
inherited;
while not Terminated do
begin
Synchronize(fixsize);
Synchronize(getscreen);
r := bmp.Canvas.ClipRect;
try
CI.cbSize := SizeOf(CI);
if GetCursorInfo(CI) then
if CI.Flags = CURSOR_SHOWING then
begin
Icon.Handle := CopyIcon(CI.hCursor);
if GetIconInfo(Icon.Handle, II) then
begin
bmp.Canvas.Draw(
ci.ptScreenPos.x - Integer(II.xHotspot) - r.Left - Form4.Left,
ci.ptScreenPos.y - Integer(II.yHotspot) - r.Top - Form4.Top,
Icon
);
end;
end;
finally
end;
try
png.Assign(bmp);
png.CompressionLevel := 9;
png.SaveToStream(stream);
stream.Position :=0;
Recblock.Command :='STREAM';
Recblock.Msg :='';
Recblock.NameFrom := MyName;
Synchronize(send);
finally
end;
try
thumbRect.Left := 0;
thumbRect.Top := 0;
if bmp.Width > bmp.Height then
begin
thumbRect.Right := maxWidth;
thumbRect.Bottom := (maxWidth * bmp.Height) div bmp.Width;
end
else
begin
thumbRect.Bottom := maxHeight;
thumbRect.Right := (maxHeight * bmp.Width) div bmp.Height;
end;
Synchronize(stretch);
bmp.Width := thumbRect.Right;
bmp.Height := thumbRect.Bottom;
Synchronize(showthumb);
finally
end;
sleep(200);
end;
end;
procedure TCaptureThread.getscreen;
begin
DC:=GetDC(0);
bitblt(bmp.Canvas.Handle, 0, 0, Form4.Width+Form4.Left, Form4.Height+Form4.Top,
DC, Form4.Left, Form4.Top, SRCCOPY);
ReleaseDC(0, DC);
end;
procedure TCaptureThread.fixsize;
begin
maxWidth := Form1.DesktopImage.Width;
maxHeight := Form1.DesktopImage.Height;
bmp.Height:=Form4.Height;
bmp.Width:=Form4.Width;
end;
procedure TCaptureThread.send;
begin
Form1.Streamclient.IOHandler.Write(RawToBytes(Recblock,sizeof(recblock)),sizeof(recblock));
Form1.Streamclient.IOHandler.Write(stream,stream.Size,true);
end;
procedure TCaptureThread.showthumb;
begin
Form1.DesktopImage.Picture.Assign(bmp);
end;
procedure TCaptureThread.stretch;
begin
SetStretchBltMode(bmp.Canvas.Handle, HALFTONE);
StretchBlt(bmp.Canvas.Handle,0,0,thumbRect.Right,thumbRect.Bottom,bmp.Canvas.Handle,0,0,bmp.Width,bmp.Height,SRCCOPY);
end;
First in my delphi 2010 i must replace
unit CaptureUnit;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs;
with
unit CaptureUnit;
interface
uses
Windows, Messages, SysUtils, Variants,
Classes, Graphics, Controls, Forms, Dialogs;
The same also in unit.pas
You should not assign a Bitmap to Picture.Assign(bmp);
procedure TCaptureThread.showthumb;
begin
CaptureForm.DesktopImage.Picture.Assign(bmp);
end;
After a short time I get also an error EOutOfResources).
You should assign a Bitmap to Picture.Bitmap.Assign(bmp);
procedure TCaptureThread.showthumb;
begin
CaptureForm.DesktopImage.Picture.Bitmap.Assign(bmp);
end;
after I changed it, I got your program run for 20 minutes without getting an error. Then I finished it manually.
Update:
Screenshot : program running while Vcl Video playing and stretching and moving the Capture Area.
Hope it helps you.
Solved the problem. Wrote the code in Synchronize(), except PNG compression and before compression used method Canvas.Lock, after compression Canvas.UnLock. This allows you to avoid the influence of the another thread to Canvas. Thanks for bummi's advice(TCanvas is not threadsave). Correctly Execute method is here:
procedure TCaptureThread.Execute;
begin
inherited;
while not Terminated do
begin
Synchronize(size);
Synchronize(getscreen);
Synchronize(drawcursor);
try
png.Canvas.Lock;
bmp.Canvas.Lock;
png.Assign(bmp);
png.CompressionLevel := 9;
png.Canvas.Unlock;
bmp.Canvas.Unlock;
finally
end;
try
Synchronize(stretch);
Synchronize(showthumb);
finally
end;
sleep(200);
end;
end;

Delphi2006 - Is there TList with TMultiReadExclusiveWriteSynchronizer?

I have external application that is multithreaded and this app is using my custom dll to do some things from that threads.
In this dll I have 2 functions that read from and write some data to TList.
I need that list to be freely read by those threads but only one can write at a time, the rest must wait for their time to write.
My question:
- is there in BDS 2006 a TList component that have TMREWSync capability or
- maybe You know any free third-party component that I can use in my app or
- maybe You have some customized TList code that can do things like this mentioned above.
Edit:
I need something like TThreadList.LockList but only for writing to that list.
Thanks for any help.
It's simple enough to put together a TMultiReadExclusiveWriteSynchronizer and TList in the same manner as TThreadList. If you already know how these classes work, then you'll be able to follow the code below.
type
TReadOnlyList = class
private
FList: TList;
function GetCount: Integer;
function GetItem(Index: Integer): Pointer;
public
constructor Create(List: TList);
property Count: Integer read GetCount;
property Items[Index: Integer]: Pointer read GetItem;
end;
TMREWList = class
private
FList: TList;
FReadOnlyList: TReadOnlyList;
FLock: TMultiReadExclusiveWriteSynchronizer;
public
constructor Create;
destructor Destroy; override;
function LockListWrite: TList;
procedure UnlockListWrite;
function LockListRead: TReadOnlyList;
procedure UnlockListRead;
end;
{ TReadOnlyList }
constructor TReadOnlyList.Create(List: TList);
begin
inherited Create;
FList := List;
end;
function TReadOnlyList.GetCount: Integer;
begin
Result := FList.Count;
end;
function TReadOnlyList.GetItem(Index: Integer): Pointer;
begin
Result := FList[Index];
end;
{ TMREWList }
constructor TMREWList.Create;
begin
inherited;
FList := TList.Create;
FReadOnlyList := TReadOnlyList.Create(FList);
FLock := TMultiReadExclusiveWriteSynchronizer.Create;
end;
destructor TMREWList.Destroy;
begin
FLock.Free;
FReadOnlyList.Free;
FList.Free;
inherited;
end;
function TMREWList.LockListWrite: TList;
begin
FLock.BeginWrite;
Result := FList;
end;
procedure TMREWList.UnlockListWrite;
begin
FLock.EndWrite;
end;
function TMREWList.LockListRead: TReadOnlyList;
begin
FLock.BeginRead;
Result := FReadOnlyList;
end;
procedure TMREWList.UnlockListRead;
begin
FLock.EndRead;
end;
This is the most basic implementation possible. If you wish you could add some more bells and whistles in the manner of TThreadList.

Use the cpu 100%

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.

Delphi 2010: No thread vs threads

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.

Resources