We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Course Of The Month
8 days, 12 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Wait for thread to finish ?
Posted on 2006-07-16
Can someone write me some examples how to make that only X numbers of threads are running at the same time. For example if i have code like this http://www.experts-exchange.com/Programming/Programming_Languages/Delphi/Q_21912741.html (accepted answer code). How can i limit that only X numbers of threads are running at the same time. In this code there is while loop which crates threads and i want to add future of max running threads at the same time.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
6
5
3
14 Comments
You can use a thread counter, and wait for the thread limit to be less that a specified max limit before spawing a new thread. Example based off the code I gve you.
Russell
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
type
TFormMailSender = class(TForm)
...
end;
type
TThreadSender = class(TThread)
private
// Private declarations
FForm: TFormMailSender;
FMailSend: TStringList;
FIDHTTP: TIdHTTP;
FMailRecv: String;
FRelayURL: String;
FMail: String;
protected
// Protected declarations
procedure AfterSend;
procedure BeforeSend;
procedure Execute; override;
public
// Public declarations
constructor Create(Form: TFormMailSender; Mail: String);
end;
const
MaxThreads = 5;
var
FormMailSender: TFormMailSender;
ThreadCounter: Integer = 0;
implementation
{$R *.DFM}
procedure TThreadSender.BeforeSend;
begin
// Get relay url
FRelayURL:=FForm.EditSmtpR
// Get post parameters
FMailSend.Values['email']:
FMailSend.Values['html']:=
FMailSend.Values['subject'
FMailSend.Values['from']:=
FMailSend.Values['fromname
end;
procedure TThreadSender.AfterSend;
begin
// Call in the main thread
FForm.Memo1.Text:=FMailRec
end;
procedure TThreadSender.Execute;
begin
// Create http component for mailing
FIDHTTP:=TIdHTTP.Create(nil);
// Resource protection
try
// Create string list for sending
FMailSend:=TStringList.Cre
// Resource protection
try
// Get post parameters
Synchronize(BeforeSend);
// Perform the post
FMailRecv:=FIDHTTP.Post(FR
// Set results
Synchronize(AfterSend);
finally
// Free string list
FMailSend.Free;
end;
finally
// Free component
FIDHTTP.Free;
// Drop the thread counter
InterlockedDecrement(Threa
end;
end;
constructor TThreadSender.Create(Form:
begin
// Increase the thread counter
InterlockedIncrement(Threa
// Set parameters
FForm:=Form;
FMail:=Mail;
SetLength(FRelayURL, 0);
// Perform inherited (don't suspend)
inherited Create(False);
// Set thread props
FreeOnTerminate:=True;
Priority:=tpLower;
end;
procedure TFormMailSender.Button1Cli
var count: Integer;
dwThreads: Integer;
Mail: String;
begin
Count:=0;
while (Count < MemoList.Lines.Count) do
begin
while True do
begin
try
InterlockedIncrement(Threa
finally
dwThreads:=InterlockedDecr
end;
if (dwThreads < MaxThreads) then
break
else
Application.ProcessMessage
end;
Mail:=MemoList.Lines.Strin
TThreadSender.Create(Self,
Inc(Count);
end;
end;
end.
The secure way is by using a semaphore, and I'll add a sample console application to show how it works. (Am using just the Windows API here, since it's not that complex...)
program ThreadPool;
{$APPTYPE CONSOLE}
uses
Windows;
var
// Semaphore, to keep the limit.
Semaphore: THandle;
// Critical section so threads don't disturb each other.
Section: TRTLCriticalSection;
function SomeThread(Parameter: Pointer): Integer;
var
I: Integer;
begin
// Thread function must return result.
Result := 0;
// Wait for the semaphore, which limits us to 10 threads.
if (WaitForSingleObject(Semap
begin
try
for I := 1 to 5 do
begin
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ': ', I: 2);
finally LeaveCriticalSection(Secti
end;
Sleep(100);
end;
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ' done');
finally LeaveCriticalSection(Secti
end;
finally ReleaseSemaphore(Semaphore
end;
end;
end;
const
InitialCount = 10;
MaximumCount = 10;
var
Threads: array[1..50] of THandle;
ThreadID: Cardinal;
I: Integer;
begin
// Semaphore for the limit of 10 threads.
Semaphore := CreateSemaphore(nil, InitialCount, MaximumCount, nil);
// Critical section for thread-0safe access to console.
InitializeCriticalSection(
// Just starting 50 threads.
for I := Low(Threads) to High(Threads) do
begin
Threads[I] := BeginThread(nil, 0, SomeThread, Pointer(I), 0, ThreadID);
// Let the thread do some actions now.
Sleep(0);
end;
// Now wait for all threads to finish.
WaitForMultipleObjects(Len
// End of critical section.
DeleteCriticalSection(Sect
// Close the semaphore.
CloseHandle(Semaphore);
// All done.
WriteLn('All done.');
end.
Okay, some explanation. Since I wanted to keep this a short example, I used BeginThread for the thread and not a TThread class. When you're doing simple thread actions, this often tends to be easier, if you're familiar with the Windows API. But normally this code would be inside your Execute method of your own TThread class.
Since I'm generating output to the consolde I added a critical section for synchronisation purposes. So all WriteLn statements are protected by them. Synchronisation is always a bit troublesome with threads since you have to think them through thoroughly.
But the main task is done by the semaphore. The application starts by generating a semaphore. I want a maximum of 10 threads active at the same time, even though I have generated 50 threads! (The others will just sleep until the semaphore activates one of them again.) The InitialCount is there to tell the system how many available 'slots' there are. With a semaphore, you can release additional slots up to the maximum. (Maximum in this case is 10.)
Every thread will have to wait until the semaphore has a free slot for them. So in the beginning, 10 threads will almost immediately execute. The 11th thread will just have to wait until one of the other threads is finished. Once a thread releases the semaphore, a slot is available again which can trigger the next thread.
Of course there is no limitation in the numer of times a single thread can wait for a free slot and release it again, as long as you make sure the slots are ALWAYS released. (Hence the try-finally construction.)
But because this is a console application and the main thread will finish after starting all 50 threads, I decided that I would also want to wait for all threads to be finished. This you can do again simply by waiting for them. This time by waiting for multiple objects, which is why I need all thread handles in a single array. Btw, you would only have to wait for all threads to be finished only when you e.g. close your application.
This method is quite safe to use, especially since the semaphore will do all the counting checks for you. And basically it means you can start hundreds of threads at the same time and your system will still limit them to a limited number.
program ThreadPool;
{$APPTYPE CONSOLE}
uses
Windows;
var
// Semaphore, to keep the limit.
Semaphore: THandle;
// Critical section so threads don't disturb each other.
Section: TRTLCriticalSection;
function SomeThread(Parameter: Pointer): Integer;
var
I: Integer;
begin
// Thread function must return result.
Result := 0;
// Wait for the semaphore, which limits us to 10 threads.
if (WaitForSingleObject(Semap
begin
try
for I := 1 to 5 do
begin
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ': ', I: 2);
finally LeaveCriticalSection(Secti
end;
Sleep(100);
end;
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ' done');
finally LeaveCriticalSection(Secti
end;
finally ReleaseSemaphore(Semaphore
end;
end;
end;
const
InitialCount = 10;
MaximumCount = 10;
var
Threads: array[1..50] of THandle;
ThreadID: Cardinal;
I: Integer;
begin
// Semaphore for the limit of 10 threads.
Semaphore := CreateSemaphore(nil, InitialCount, MaximumCount, nil);
// Critical section for thread-0safe access to console.
InitializeCriticalSection(
// Just starting 50 threads.
for I := Low(Threads) to High(Threads) do
begin
Threads[I] := BeginThread(nil, 0, SomeThread, Pointer(I), 0, ThreadID);
// Let the thread do some actions now.
Sleep(0);
end;
// Now wait for all threads to finish.
WaitForMultipleObjects(Len
// End of critical section.
DeleteCriticalSection(Sect
// Close the semaphore.
CloseHandle(Semaphore);
// All done.
WriteLn('All done.');
end.
Okay, some explanation. Since I wanted to keep this a short example, I used BeginThread for the thread and not a TThread class. When you're doing simple thread actions, this often tends to be easier, if you're familiar with the Windows API. But normally this code would be inside your Execute method of your own TThread class.
Since I'm generating output to the consolde I added a critical section for synchronisation purposes. So all WriteLn statements are protected by them. Synchronisation is always a bit troublesome with threads since you have to think them through thoroughly.
But the main task is done by the semaphore. The application starts by generating a semaphore. I want a maximum of 10 threads active at the same time, even though I have generated 50 threads! (The others will just sleep until the semaphore activates one of them again.) The InitialCount is there to tell the system how many available 'slots' there are. With a semaphore, you can release additional slots up to the maximum. (Maximum in this case is 10.)
Every thread will have to wait until the semaphore has a free slot for them. So in the beginning, 10 threads will almost immediately execute. The 11th thread will just have to wait until one of the other threads is finished. Once a thread releases the semaphore, a slot is available again which can trigger the next thread.
Of course there is no limitation in the numer of times a single thread can wait for a free slot and release it again, as long as you make sure the slots are ALWAYS released. (Hence the try-finally construction.)
But because this is a console application and the main thread will finish after starting all 50 threads, I decided that I would also want to wait for all threads to be finished. This you can do again simply by waiting for them. This time by waiting for multiple objects, which is why I need all thread handles in a single array. Btw, you would only have to wait for all threads to be finished only when you e.g. close your application.
This method is quite safe to use, especially since the semaphore will do all the counting checks for you. And basically it means you can start hundreds of threads at the same time and your system will still limit them to a limited number.
Additional note: If you add the following code to the thread function BEFORE the WaitForSingleObject line then you can see when the threads are created.
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ' created');
finally LeaveCriticalSection(Secti
end;
And when you use it, you will see that all threads are created almost immediately. So this solution will mean you have 50 threads at some point.
Also, after the line WaitForMultipleObjects you will need to add these lines:
for I := Low(Threads) to High(Threads) do
CloseHandle(Threads[I]);
Yes, I forgot to close all the threads... :-) For this example it's not important, though. And the TThread class will do this for you automatically.
Anyway, my approach will differ a bit from what you wanted because in my approach there is no limit to the number of created threads. It's just that most of them will be asleep and thus eat no processor time. (Just system resources.) Basically, the advantage of this is that you don't have to control the creation of the threads and put a limit there. You just put the limit in the threads themselves so your main thread doesn't have to be bothered about it.
Of course, what you could also do is wait for e.g. 5000 milliseconds instead of INFINITE. Then WaitForSingleObject will return the value WAIT_TIMEOUT instead and in my example this would mean the code inside the thread won't be executed. This would be a time-out implementation, again arranged entirely from inside the thread.
Also keep in mind that although I create the threads in a simple order, there is no way of telling in which order the threads will finish, even though all execute exactly the same code and thus should all take about the same amount of time.) The only guarantee you have is that 10 threads will be running, an d no more than 10. All other threads, while active, are all asleep. Threads that are asleep eat no CPU cycles. They are activated by the semaphore when a slot is released.
EnterCriticalSection(Secti
try
WriteLn('Thread ', Integer(Parameter), ' created');
finally LeaveCriticalSection(Secti
end;
And when you use it, you will see that all threads are created almost immediately. So this solution will mean you have 50 threads at some point.
Also, after the line WaitForMultipleObjects you will need to add these lines:
for I := Low(Threads) to High(Threads) do
CloseHandle(Threads[I]);
Yes, I forgot to close all the threads... :-) For this example it's not important, though. And the TThread class will do this for you automatically.
Anyway, my approach will differ a bit from what you wanted because in my approach there is no limit to the number of created threads. It's just that most of them will be asleep and thus eat no processor time. (Just system resources.) Basically, the advantage of this is that you don't have to control the creation of the threads and put a limit there. You just put the limit in the threads themselves so your main thread doesn't have to be bothered about it.
Of course, what you could also do is wait for e.g. 5000 milliseconds instead of INFINITE. Then WaitForSingleObject will return the value WAIT_TIMEOUT instead and in my example this would mean the code inside the thread won't be executed. This would be a time-out implementation, again arranged entirely from inside the thread.
Also keep in mind that although I create the threads in a simple order, there is no way of telling in which order the threads will finish, even though all execute exactly the same code and thus should all take about the same amount of time.) The only guarantee you have is that 10 threads will be running, an d no more than 10. All other threads, while active, are all asleep. Threads that are asleep eat no CPU cycles. They are activated by the semaphore when a slot is released.
Finally, one minor warning... WaitForMultipleObjects cannot wait for more than MAXIMUM_WAIT_OBJECTS objects, which means that there's a maximum limit of 64 threads. If you have more than 64 threads then you will need this solution:
// Now wait for all threads to finish.
I := Low(Threads);
while (I < High(Threads)) do
begin
Count := Length(Threads) + 1 - I;
if (Count > MAXIMUM_WAIT_OBJECTS) then Count := MAXIMUM_WAIT_OBJECTS;
WaitForMultipleObjects(Cou
I := I + Count;
end;
You would also have to use this solution when you would be using a dynamic array for your threads. (And add a variable Count:Integer to your Var section.) Then again, you would only need this when you want to wait for all the threads to finish. And there are many other ways to do this waiting. It's just that I wanted to make this a better example.
// Now wait for all threads to finish.
I := Low(Threads);
while (I < High(Threads)) do
begin
Count := Length(Threads) + 1 - I;
if (Count > MAXIMUM_WAIT_OBJECTS) then Count := MAXIMUM_WAIT_OBJECTS;
WaitForMultipleObjects(Cou
I := I + Count;
end;
You would also have to use this solution when you would be using a dynamic array for your threads. (And add a variable Count:Integer to your Var section.) Then again, you would only need this when you want to wait for all the threads to finish. And there are many other ways to do this waiting. It's just that I wanted to make this a better example.
rllibby:
Your solutions looks nice and simple but i can't use Application.ProcessMessage
Workshop_Alex:
It is a little complicated for me to rewrite your code for my code, so it would be nice if you could do it.
Your solutions looks nice and simple but i can't use Application.ProcessMessage
Workshop_Alex:
It is a little complicated for me to rewrite your code for my code, so it would be nice if you could do it.
How do you plan on waiting then? Eg, you have 10 lines to process, you want 5 max threads, you spin off 5 threads to work on the first 5 lines, how do you intend to wait for one of the threads to finish so you process the remaining 5 lines?
Russell
Application.ProcessMessage
Russell
I can't get this working. Meybe it would be uasier to write code that will do the folowing:
- create thread
- wait for this thread to finish
- create another thread
- create thread
- wait for this thread to finish
- create another thread
Application.ProcessMessage
Still, I myself would suggest that you use some threadpool in some way. Or else as you suggest yourself, start them one by one.
Still, I myself would suggest that you use some threadpool in some way. Or else as you suggest yourself, start them one by one.
Yes this is why i want to start 1 thread and wit for this thread to finish and then start another one. Can someone write me pice of code that will wait for 1 thread to finish and then start another one.
Thank you.
Thank you.
Actually, you don't want to wait for the thread to finish because while your are waiting, the thread that does the waiting will be frozen...
If you create a thread by inheriting from TThread then you have an OnTerminate event which will be called right before the thread finishes. You can use that event to trigger the next event.
Unfortunately, maintaining many threads, either one by one or as a pool, can become a complex experiment. You will have to keep track of lots of possible issues. We can write some code for you based on the information you have given us but that's no use because something else in your code might cause something that will make the system fall down again. It is more useful if you understand the way threads work and then create what you need yourself. Especially considering what you are trying to do here.
If you create a thread by inheriting from TThread then you have an OnTerminate event which will be called right before the thread finishes. You can use that event to trigger the next event.
Unfortunately, maintaining many threads, either one by one or as a pool, can become a complex experiment. You will have to keep track of lots of possible issues. We can write some code for you based on the information you have given us but that's no use because something else in your code might cause something that will make the system fall down again. It is more useful if you understand the way threads work and then create what you need yourself. Especially considering what you are trying to do here.
I think that this OnTerminate event would be fine, could you write me something that would work with this. I think that it would look like this. OnTerminate event will set some golbal veribale to TRUE and in man form there will be code which will check for if this variable set to TRUE and then create new thread and set varibale back to false. I'm i right ? Can you write somthing like this please ?
Featured Post
Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Objective:
- This article will help user in how to convert their numeric value become words.
How to use
1. You can copy this code in your Unit as function
2. than you can perform your function by type this code
The Code
Â
(CODE)
The Im…
In my programming career I have only very rarely run into situations where operator overloading would be of any use in my work. Normally those situations involved math with either overly large numbers (hundreds of thousands of digits or accuracy re…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Suggested Courses
Course of the Month8 days, 12 hours left to enroll
Earn Certification
CompTIA IT Fundamentals
$49.00$44.10
734 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.