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!
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
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!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Introduction
The parallel port is a very commonly known port, it was widely used to connect a printer to the PC, if you look at the back of your computer, for those who don't have newer computers, there will be a port with 25 pins and a small print…
Hello everybody
This Article will show you how to validate number with TEdit control,
What's the TEdit control?
TEdit is a standard Windows edit control on a form, it allows to user to write, read and copy/paste single line of text.
Usua…
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data.
But that feeling is fleeting. Attacks these days can happen in many w…
Suggested Courses
Course of the Month6 days, 23 hours left to enroll
705 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.