Selective critical section - conditional - multithreading

I got a thread which takes a db table as a paramater, I got an issue where I can't write to that db table at the same time.
1 instance of TMyThread can have a db table of 'Member' while another could have 'Staff' however there can be cases of two threads open with the same table.
Thus, I need to wrap the code in a critical section (or similar) but I don't want some dirty thing like several crical sections like (fMemberTable, fStaffTable)...
begin
if fDBTable = 'Member' then
fMemberTable.Enter
else if fDbTable = 'Staff' then
....
We have 8 tables so that would get messy
Is there some way to do
TCricalSection(fMemberTable).Enter;
Or some way to do this which is easy to 'scale' and use?
One critical section around the function doesn't make sense, as I don't want to hold back other tables....

You can do:
TMonitor.Enter(fMemberTable);
try
// Do your stuff
finally TMonitor.Exit(fMemberTable);
end;
Please note this is a SPIN LOCK, not a true critical section. Very practical if you're not going to have a lot of collisions, but if threads block each other regularly, you might want to fall back to the critical section. The spin lock is, by definition, a busy-wait lock.
but I'm not sure what version of Delphi introduced this and you don't have version-specific tags.

You can use a Critical Section list, for example, My class defined in this unit:
interface
uses Classes, SyncObjs;
type
{ TCriticalSectionList by jachguate }
{ http://jachguate.wordpress.com }
TCriticalSectionList = class
private
FCSList: TThreadList;
FNameList: TStringList;
function GetByName(AName: string): TCriticalSection;
public
constructor Create();
destructor Destroy(); override;
property ByName[AName: string]: TCriticalSection read GetByName; default;
end;
function CSList: TCriticalSectionList;
implementation
uses SysUtils;
{ TCriticalSectionList }
constructor TCriticalSectionList.Create;
begin
inherited;
FCSList := TThreadList.Create;
FNameList := TStringList.Create;
end;
destructor TCriticalSectionList.Destroy;
var
I: Integer;
AList: TList;
begin
AList := FCSList.LockList;
for I := AList.Count - 1 downto 0 do
TCriticalSection(AList[I]).Free;
FCSList.Free;
FNameList.Free;
inherited;
end;
function TCriticalSectionList.GetByName(AName: string): TCriticalSection;
var
AList: TList;
AIdx: Integer;
begin
AList := FCSList.LockList;
try
AName := UpperCase(AName);
AIdx := FNameList.IndexOf(AName);
if AIdx < 0 then
begin
FNameList.Add(AName);
Result := TCriticalSection.Create;
AList.Add(Result);
end
else
Result := AList[AIdx];
finally
FCSList.UnlockList;
end;
end;
var
_CSList: TCriticalSectionList;
function CSList: TCriticalSectionList;
begin
if not Assigned(_CSList) then
_CSList := TCriticalSectionList.Create;
Result := _CSList;
end;
initialization
_CSList := nil;
finalization
_CSList.Free;
end.
The class basically define a List of critical sections, accesible by "name". The first time you ask for a Critical section of a particular name that critical section is automatically created for you. You must access a single instance of this class, use the provided CSList function.
All critical sections are destroyed when the instance of the list is destroyed, for instance, the "default" instance is destroyed upon application end.
You can write code like this example:
begin
CSList[fDBTable].Enter;
try
DoStuff;
finally
CSList[fDBTable].Leave;
end;
end;
Enjoy.

Related

Custom property only trigger read statement

So, I'm trying to make a component that will do the job on setting the settings of a excel, libreoffice, etc... cells. At first I just wanted to set the value, but now, I need to change cell background color, change font name, style, set a formula, etc... So for that, I decided to do a type that will hold all the things I want to change and so, I did this:
type
TMyCell = class
private
FBgColor: TColor;
FValue: String;
FFormula: String;
FFormat: String;
FFont: TFont;
public
constructor Create;
destructor Destroy;
property Value: String read FValue write FValue;
property Formula: String read FFormula write FFormula;
property Format: String read FFormat write FFormat;
property BgColor: TColor read FBgColor write FBgColor;
property Font: TFont read FFont write FFont;
end;
{ TMyCell }
constructor TMyCell.Create;
begin
FFont := TFont.Create;
end;
destructor TMyCell.Destroy;
begin
FFont.Free;
end;
And my component look like this:
type
TMyPlan = class(TComponent)
private
FExcel: Variant;
procedure SetMyCell(Row, Column: Integer; Value: TMyCell);
function GetMyCell(Row, Column: Integer): TMyCell;
public
constructor Create(AOwner: TComponent);
destructor Destroy;
property Cell[Row, Column: Integer]: TMyCell read GetMyCell write SetMyCell;
end;
{ TMyPlan }
constructor TMyPlan.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FExcel := CreateOleObject('Excel.Application');
FExcel.Workbooks.Add(1);
end;
destructor TMyPlan.Destroy;
begin
FExcel := Unassigned;
inherited;
end;
function TMyPlan.GetMyCell(Row, Column: Integer): TMyCell;
begin
Result := TMyCell.Create;
Result.Value := FExcel.Cells[Row, Column];;
end;
procedure TMyPlan.SetMyCell(Row, Column: Integer; Value: TMyCell);
begin
FExcel.Cells[Row, Column] := Value.Value;
end;
Just to let you know, I already did some components, and I'm still learning how to do them properly, so this may have a not decent structure, anyway, this is the first time that I'm trying to do something like this, a property that has input parameters with subproperties, and it doesn't seem to work as I though it would.
Back to the topic, it doesn't matter how I call my property
Set: MyPlan.Cell[1, 1].Value := '1';
Get: ShowMessage(MyPlan.Cell[1, 1].Value);
Either way only the GetMyCell function is triggered. Why's that?
See my answer to this question: "Left side cannot be assigned to" for record type properties in Delphi
While what you're doing isn't quite the same thing, it is similar. However, in your case, you're allocating a new instance of TMyCell for every access to GetMyCell. This "temporary" instance is isn't being freed and will leak (Unless you're doing this on one of the ARC platforms).
The reason your SetMyCell isn't being called is because you're not actually setting the cell itself, rather you're setting a value on the cell instance (that I explained above is leaking).

merge paint results in thread bitmap painting

I want to speed up painting a bitmap, therefore I designed a class like BITMAP THREAD CLASS. Once the individual painting of a partial image is finished I want to merge all image in the Thread.done procedure
My code goes like this
type
TbmpthreadForm = class(TForm)
.....
THreadImage: TImage;
procedure Button_threadstartClick(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
private
{ Private-Deklarationen }
procedure ThreadDone(Sender: TObject);
public
{ Public-Deklarationen }
fserver, fdatabasename, ftablename: String;
global_thread_counter: Integer;
XPixel, YPixel: Integer;
Masterbitmap: TBitmap;
end;
var
bmpthreadForm: TbmpthreadForm;
implementation
{$R *.dfm}
procedure TbmpthreadForm.ThreadDone(Sender: TObject);
begin
dec(global_thread_counter);
MyStatusBar.SimpleText := 'Thread Count ->' + IntToStr(global_thread_counter);
Masterbitmap.Canvas.Lock;
with (Sender as TPaintBitmapThread) do
begin
bitblt(Masterbitmap.Canvas.handle, 0, 0, XPixel, YPixel,
bitmap.Canvas.handle, 0, 0, srcand);
THreadImage.Picture.Bitmap.Assign(Masterbitmap);
// lets see local tthread intermediate results and save it to HD
THreadImage.Picture.Bitmap.SaveToFile('c:\temp\myimage' + IntToStr(Index)
+ '.bmp');
end;
Masterbitmap.Canvas.UnLock;
if (global_thread_counter = 0) then
begin
...
end;
end;
procedure TbmpthreadForm.Button_threadstartClick(Sender: TObject);
var
.....
begin
index_max := 2000000;
threadCounter := 10;
Indexdelta := round(index_max / threadCounter);
///
///
....
Masterbitmap.Width := XPixel;
Masterbitmap.Height := YPixel;
for i := 0 to threadCounter - 1 do
begin
n := i * Indexdelta;
m := (i + 1) * Indexdelta;
// just a test sql string ....
sqlstr := 'select * from Mytable where objectindex <' + IntToStr(m) +
' and Objectindex >' + IntToStr(n);
aPaintBitmapThread := TPaintBitmapThread.Create(XPixel, YPixel, ...... , fserver, fdatabasename, ftablename,
sqlstr, i);
aPaintBitmapThread.OnTerminate := ThreadDone;
Memo1.Lines.Add('start thread->' + IntToStr(i));
inc(global_thread_counter);
end;
end;
The Thread.done design follows a previous topic here on SO ( reference question
As the resulting image/Masterbitmap looks a bit different from run to run , I guess my approach is not thread safe design for copy Thread bmp content into the masterbitmap in the VCL mainform,
I can not see any error in my code, what is wrong ????
additional question
Q1 : fbitmap inside TPaintBitmapThread is created inside the Thread.create procedure, for TAdoconnection I found the comment, it should be created inside the thread.execute. Must this also be done the the bitmap ?
Q2 : the attached image shows the expected result of an image(Bitmap) by an Thread and the actual image results (as seen by the THreadImage.Picture.Bitmap.SaveToFile command)
bitblt(Masterbitmap.Canvas.handle, 0, 0, XPixel, YPixel,
bitmap.Canvas.handle, 0, 0, srcand);
you explicitly called Masterbitmap.Canvas.Lock, however you didn't call bitmap.Canvas.Lock (so you can loose the canvas handle anytime within this call...)
Additionally, you need to consider thread safety within GDI itself: Sharing of any GDI objects between different threads should be avoided at all cost. For example if you select a bitmap into two different device contexts at the same time (but in different threads) you may run into problems within GDI itself...
Please note that older versions of delphi don't protect against sharing of cached handles (Font, Brush and Pen handles are cached within a global list. This was fixed in an XE3 service pack if I remember correctly).
In short: I'd consider to avoid TCanvas and TBitmap completely if you really need multi-threading. (It's much easier to be multi-threading safe that way)

Delphi: one thread cannot see other thread's array

ANSWER:
Allright, that was quite simple (probably I made this mistake coz I need more sleep :) ):
I've created First Thread and it created Sub-Threads and FREE-ed it-self. So it was naturall that some sub-thread souldn't access not existing memory (before they tryed - First Thread wasn`t already in memory).
Hi,
I'm trying to make simple application.
My needs are to create for example 1-3 threads (I will call them First Threads), which will create next few threads (I will call them Sub-Threads).
I know how to do it, this is what I have done:
First Thread definition:
type
TFirstThread = class(TThread)
//
strict private
fID:cardinal; //fID = position on watki array + 1
fDoneItems:cardinal;
fItems:TSomeRecordAr;
//(...)
procedure ParseItem(var item: TSomeRecord; itemID:cardinal);
private
public
published
function GetItem(itemindex:cardinal):TSomeRecord;
procedure SetItem(itemindex: cardinal; item: TSomeRecord);
//(...)
procedure Execute; override;
end;
TSomeRecord is:
TSomeRecord = record
str,str2:string;
lst:TStrings;
continue:boolean;
end;
Sub-Thread definition:
TSubThread = class(TThread)
public
fReady:boolean;
fID,fItemID:cardinal;
procedure Execute; override;
end;
And also array of First Threads:
watki:array of TFirstThread;
Body of First Threads:
{ TFirstThread }
//(...)
procedure TFirstThread.ParseItem(var item:TSomeRecord; itemID:cardinal);
begin
//(...)
with TSubThread.Create(False) do begin
fID:=Self.fID;
fItemID:=itemID;
fReady:=True;
end;
end;
procedure TFirstThread.Execute;
var
i:cardinal;
begin
FreeOnTerminate:=True;
while fReady=False do
Sleep(10);
//(...)
fDoneItems := 1;
for i := 0 to High(fItems) do begin
ParseItem(fItems[i], i);
end;
//
end;
function TFirstThread.GetItem(itemindex: cardinal): TSomeRecord;
begin
result:=fItems[itemindex];
end;
procedure TFirstThread.SetItem(itemindex: cardinal; item: TSomeRecord);
begin
fItems[itemindex]:=item;
end;
Body of Sub-Threads:
procedure TSubThread.Execute;
var
ftd:string;
tries:cardinal;
fItem:TSomeRecord;
begin
FreeOnTerminate:=True;
while fReady=False do
Sleep(10);
try
//(...)
fItem := watki[fID-1].GetItem(fItemID); //HERE AV <<
fItem.continue:=True;
//(...)
finally
watki[fID-1].SetItem(fItemID, fItem);
//(...)
//Free;
end;
end;
This is how doeas it looks in practice:
While I'm testing, I'm creating just 1 First Thread and start it. It has 3 items, so it creates 3 Sub-Threads.
When I make breakpoint in TFirstThread this is what I can see:
http://i.stack.imgur.com/EGaBO.jpg
everything is OK,
but after that when I make breakpoint in TSubThread this is what i get:
http://i.stack.imgur.com/gXhHW.jpg
so everithing is OK except fItems - idk why, but I can't see it's content. So ofc I get AV, coz item I want to get doesn't exist.
Why can it be like that? Any solutions?
Thanks in advance.
Btw I'm using Delphi 2009
ANSWER:
Allright, that was quite simple (probably I made this mistake coz I need more sleep :) ):
I've created First Thread and it created Sub-Threads and FREE-ed it-self. So it was naturall that some sub-thread souldn't access not existing memory (before they tryed - First Thread wasn`t already in memory).
Allright, that was quite simple (probably I made this mistake coz I need more sleep :) ): I've created First Thread and it created Sub-Threads and FREE-ed it-self. So it was naturall that some sub-thread souldn't access not existing memory (before they tryed - First Thread wasn`t already in memory).

Are `const` string parameters (thread) safe

This code
procedure MyThreadTestA(const AStr: string);
Is faster than
procedure MyThreadTestB(AStr: string);
Whilst doing the same work, both pass a pointer.
However version B 'correctly' updates the referencecount of AStr and makes a copy if I change it.
Version A passes just a pointer and only the compiler prevents me from changing AStr.
Version A is not safe if I do dirty tricks in Assembler or otherwise to circumvent the compiler protection, this is well known but...
Is passed AStr by reference as a const parameters thread safe?
What happens if AStr's reference count in some other thread goes to zero and the string is destroyed?
No, such tricks are not thread-safe. Const prevents the add-ref, so changes by another thread will affect the value in unpredictable ways. Sample program, try altering the const in the definition of P:
{$apptype console}
uses SysUtils, Classes, SyncObjs;
type
TObj = class
public
S: string;
end;
TWorker = class(TThread)
public
procedure Execute; override;
end;
var
lock: TCriticalSection;
obj: TObj;
procedure P(const x: string);
// procedure P(x: string);
begin
Writeln('P(1): x = ', x);
Writeln('Releasing obj');
lock.Release;
Sleep(10); // give worker a chance to run
Writeln('P(2): x = ', x);
end;
procedure TWorker.Execute;
begin
// wait until TMonitor is freed up
Writeln('Worker started...');
lock.Acquire;
Writeln('worker fiddling with obj.S');
obj.S := 'bar';
TMonitor.Exit(obj);
end;
procedure Go;
begin
lock := TCriticalSection.Create;
obj := TObj.Create;
obj.S := 'foo';
UniqueString(obj.S);
lock.Acquire;
TWorker.Create(False);
Sleep(10); // give worker a chance to run and block
P(obj.S);
end;
begin
Go;
end.
But it's not just limited to threads; modifying the underlying variable location has similar effects:
{$apptype console}
uses SysUtils, Classes, SyncObjs;
type
TObj = class
public
S: string;
end;
var
obj: TObj;
procedure P(const x: string);
begin
Writeln('P(1): x = ', x);
obj.S := 'bar';
Writeln('P(2): x = ', x);
end;
procedure Go;
begin
obj := TObj.Create;
obj.S := 'foo';
UniqueString(obj.S);
P(obj.S);
end;
begin
Go;
end.
To add to Barry's answer: It is definitely thread-safe if the string that got passed came from a local variable inside the callers scope.
In that case that local variable will hold a valid reference and the only way (assuming just valid pascal code, no fiddling around in asm) for that local variable to be changed is if your call returns.
This also includes all cases where the source of the string variable is the result of a function call (including property access, e.g. TStrings.Strings[]) because in this case the compiler has to store the string in a local temp variable.
Thread-safety problems can only result if you are directly passing a string from a location where that string can be changed (by the same or another thread) before your call returns.

BeginThread Structure - Delphi

I've got a almost completed app now and the next feature I want to implement is threading. I chose to go with BeginThread(), although am aware of TThread in delphi. The problem I'm coming across is the structure of BeginThread() call. Normally the line in the program that would call the function I want to be threaded is
CompareFiles(form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op);
op is a integer.
The line I've switched it out for to create a thread from it is
BeginThread(nil,0,CompareFiles,Addr('form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op'),0,x);
From the little amount of infromation I can find on how to actually use BeginThread() this should be a fine call, however on compling all I get is complier errors regarding the structure of my BeginThread() statement paramenters.
EDIT FOR INFORMATION.
The current procedure that calls CompareFiles is
procedure TForm1.Panel29Click(Sender: TObject);
var
op,x : integer;
begin
if (Form1.Edit3.Text <> '') AND (Form1.Edit4.Text <> '') then
begin
op := 3;
if RadioButton7.Checked = True then op := 0;
if RadioButton3.Checked = True then op := 1;
if RadioButton4.Checked = True then op := 2;
if RadioButton5.Checked = True then op := 3;
if RadioButton6.Checked = True then op := 4;
CompareFiles(form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op);
end;
end;
If I was to use TThread as suggested by a couple of people, and as displayed by Rob below, I'm confused at how a) I would pass op,Edit3/4.Text and StringGrid2 to the CompareFiles. Guessing from the example of TThread I've seen I thought I would replace the code above with TCompareFilesThread.Executeand the put the current code from Panel29Click into TCompareFilesThread.Create and then add
FEdit3Text := Edit3Text;
FEdit4Text := Edit4Text;
FGrid := Grid;
to this
FEdit3Text := Form1.Edit3.Text;
FEdit4Text := Form1.Edit4.Text;
FGrid := Form1.StringGrid2;
But I've got this nagging feeling that is totally off the mark.
That's not at all the way to use BeginThread. That function expects a pointer to a function that takes one parameter, but the function you're trying to call wants four. The one parameter you're giving to BeginThread for it to forward to the thread procedure is a string, but you evidently hope that some sort of magic will turn that string of characters into the values that those variables contain.
That's not how Delphi works, and even for the languages that can do something like that, it's generally discouraged to actually do it.
To pass multiple parameters to BeginThread, define a record with all the values you'll need, and also define a record pointer:
type
PCompareFilesParams = ^TCompareFilesParams;
TCompareFilesParams = record
Edit3Text,
Edit4Text: string;
Grid: TStringGrid;
Op: Integer;
end;
Change CompareFiles to accept a pointer to that record:
function CompareFiles(Params: PCompareFilesParams): Integer;
To start the thread, you'll need to allocate an instance of that record and populate its fields:
var
Params: PCompareFilesParams;
begin
New(Params);
Params.Edit3Text := Edit3.Text;
Params.Edit4Text := Edit4.Text;
Params.Grid := StringGrid2;
Params.Op := op;
BeginThread(nil, 0, #CompareFiles, Params, 0, x);
Implement CompareFiles like this so that the record will get freed before the thread terminates:
function CompareFiles(Params: PCompareFilesParams): Integer;
begin
try
// <Normal implementation goes here.>
finally
Dispose(Params);
end;
end;
You can make it all a lot easier if you just use TThread, though. You can make your descendant class have as many parameters as you want in its constructor, so you don't have to mess around with dynamically allocating and freeing a special record.
type
TCompareFilesThread = class(TThread)
private
FEdit3Text,
FEdit4Text: string;
FGrid: TStringGrid;
FOp: Integer;
procedure Execute; override;
public
constructor Create(const Edit3Text, Edit4Text: string; Grid: TStringGrid; Op: Integer);
property ReturnValue;
end;
constructor TCompareFilesThread.Create;
begin
inherited Create(False);
FEdit3Text := Edit3Text;
FEdit4Text := Edit4Text;
FGrid := Grid;
FOp := Op;
end;
procedure TCompareFilesThread.Execute;
begin
ReturnValue := CompareFiles(FEdit3Text, FEdit4Text, FGrid, FOp);
end;
Instead of calling BeginThread, you just instantiate the class and let it run:
var
ThreadRef: TThread;
ThreadRef := TCompareFilesThread.Create(Edit3.Text, Edit4.Text, StringGrid2, Op);
There's more to using threads, such as knowing when the thread has finished running, but I think you have enough to get started. One last thing to beware of, though, is that TStringGrid is a VCL control. You mustn't do anything with it from this new thread you create (regardless of how you end up creating it). Eveything you do with the grid control need to be done from the main thread. Use TThread.Synchronize and TThread.Queue to shift any VCL operations onto the main thread. Your file-comparing thread will wait for the synchronized operation to complete, but it will keep running without waiting for a queued operation to complete.

Resources