• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 216
  • Last Modified:

can do 64 threads, but not 65.....

Thanks to all who helped me with threads the last few weeks, I got my app up and running and it's working pretty good... but I've hit a new and strange snag:

Seems everything works fine when I have the number of threads less than or equal to 64, but as soon as I set it to 65 or over, I get an I/O Error 104, and the debugger points to the "while not eof(tinfile) do" line of this section of code in my "worker" thread:

  while not eof(tinfile) do
  begin

   {* Start of Critical Section *}

    EnterCriticalSection(CritSect);

    readln(tinfile, thinrec);
tbytes_processed:=tbytes_processed+length(thinrec)+2;
    thperc:=Form1.calc_status(ttotsize_infile, tbytes_processed);
    if thperc >= tprevhperc+1 then
    begin
      tprevhperc:=thperc;
      Form1.gauge2.progress:=thperc;
      Form1.refresh;
    end;

    LeaveCriticalSection(CritSect);

    etc. etc.....



I'm using a "WaitForMultipleObjects" statement to wait for all my threads to finish, before proceeding. I've got a feeling the problem might lie in there....when I execute my app outside of the IDE, it *immediately* finishes in the blink of an eye (no error 104 comes up). Which leads me to believe 65 threads or greater causes a problem for the "WaitForMultipleObjects" cause it seems to fly right past it (...65 is a very suspicious number to fail at). Here's my exact code for that part of my app:


procedure TWaitThr.Execute;
var
  hndlArr : Array[0..9999] of THandle;
  thrArr : Array[0..9999] of TWorkerThread;
  I, dnsx : Integer;
begin
  FreeOnTerminate := True;

  for I := 0 to Form1.SpinEdit3.Value-1  do
  begin
    thrArr[I]:= TWorkerThread.Create(True);
    thrArr[I].Resume;
    hndlArr[I] := thrArr[I].Handle;
  end;
  WaitForMultipleObjects(Form1.SpinEdit3.Value, @hndlArr, True, INFINITE);
  Synchronize(UpdateLabel);
end;



...I call TWaitThr.Create from my main portion of my app. TWaitThr in turn calls and creates my "worker" threads.... then it waits.

Thanks!
   Shawn

P.S: I'm using D6 Enterprise version.
0
aztec
Asked:
aztec
  • 6
  • 4
1 Solution
 
MadshiCommented:
The documentation sais this about the "nCount" parameter of WaitForMultipleObjects:

"nCount

Specifies the number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS."

And guess what MAXIMUM_WAIT_OBJECTS is like? Yes, you guessed right, it's 64...   :-)

Regards, Madshi.
0
 
aztecAuthor Commented:
ahhhh! OK Madshi thanks!

But is there any way around this? Perhaps another way to "wait" ? I'd like to be able to use more than 64 threads!

Ciao
   Shawn
0
 
aztecAuthor Commented:
ahhhh Ok Madshi thanks!But is there any way around this? Perhaps a different approach to use for "wait"? I'd like to be able to use more than 64 threads.

Ciao
   Shawn
0
Industry Leaders: We Want Your Opinion!

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!

 
aztecAuthor Commented:
(sorry for the double post.... it had looked like my first didn't go thru, and I re-posted)
0
 
MadshiCommented:
Hmmm... Are you waiting until ONE of the threads is finished or until ALL of the threads are finished? If you wait until ALL of the thread are finished, you can simply call WaitForMultipleObjects with 64 threads, then another time with the next 64 threads and so on. If you wait until ONE thread is finished, it all gets more complicated.

Let me ask: For what purpose do you need so many threads (as you can see Microsoft didn't think that so many threads make sense)? And all the threads you are waiting for are your own threads, right? You could put a PostMessage call at the end of each thread, which notifies the main thread about the terminating of the thread. This way you could have a simple message loop in the main thread instead of calling WaitForMultipleObjects.

Regards, Madshi.
0
 
aztecAuthor Commented:
I am waiting for ALL the threads to finish before I proceed (and yes, they are all my own threads). I had *thought* about using more than one WaitForMultipleObjects statement...so this will work then?

Why so many threads? Just to try to get the *fastest* execution out of my app! Overkill? Maybe! :-)

Shawn
0
 
MadshiCommented:
>> Why so many threads? Just to try to get the *fastest* execution out of my app! Overkill? Maybe! :-)

Well, maybe with so many threads it will end up being slower than with only 1 thread!

Look, a thread can't do magic. Most PCs only have one CPU in it. And your program runs fastest if it uses all the CPU power. One thread can do that already, >64 threads can not make the CPU run at 110% of its power, that's not possible. So what do >64 threads bring? It will have one disadvantage: Namely the thread switching costs performance. You can say e.g. 5% of the CPU goes lost just by switching all your threads. It has one advantage, though: If the threads sometimes are waiting for something, e.g. for data to arrive at the COM port or such stuff, then threads are very good. If you had only one thread in such a situation, it would wait for the data, and the CPU would go to sleep. But when doing file stuff, multiple threads might do more damage than help. You should do some performance tests.

But back to your problem:

Let's say you have 100 threads running. If you now want to wait for ALL threads to be finished, this is exactly the same as first waiting for 64 threads to be finished, and then waiting for the remaining 36 threads to be finished. So you easily call WaitForMultipleObjects as often as you need to wait for all your threads. No problem.

Regards, Madshi.
0
 
aztecAuthor Commented:
OK, I will try the multiple "WaitForMultipleObjects" statements. Madshi, would this be the way to do it if I allow a maximum of 128 threads (user enters # of threads in Form1.SpinEdit3):


if Form1.SpinEdit3.Value <= 64 then
     WaitForMultipleObjects(Form1.SpinEdit3.Value, @hndlArr, True, INFINITE)
  else if (Form1.SpinEdit3.Value > 64) and (Form1.SpinEdit3.Value <= 128) then
  begin
    WaitForMultipleObjects(64, @hndlArr, True, INFINITE);
    WaitForMultipleObjects(Form1.SpinEdit3.Value-64, @hndlArr[64], True, INFINITE);
  end;


..does this look correct to you? I am wondering about the "@hndlArr[64]". Is this the correct way to do it, so it will start with the the 65th element of hndlArr?

Regarding hndlArr:
(1) Do I need brackets around it, like this :
 @(hndlArr[64]) ?
(2) Should I initialize all elements of the hndlArr first before using it? If so, what do I initialize it with ... a zero?

Ciao!
   Shawn
0
 
MadshiCommented:
Looks alright on a quick look.

(1) No brackets are needed.
(2) Initializing is safer, you should initialize with zero.

Regards, Madshi.
0
 
aztecAuthor Commented:
thanks Madshi - works fine!

Ciao
  Shawn
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now