Major problem with Win2000 and threads

Major problem with Win2000 and threads

Post by Andrew Cros » Mon, 12 Mar 2001 11:46:42



Hi All,

I am writing a realtime processing system that runs under Windows2000. As
time progresses within this system relatively large numbers of threads are
routinely started and stopped as part of the process. There are a couple of
main threads that coordinate the whole thing and give data to the relevant
processing threads ... To sum up the whole system as quickly as possible,
imagine whats below

Thread 1 : Thread that is always running that receives and sends data to the
actual worker-threads
Thread 2 : Thread that is always running that receives and sends data to the
actual worker-threads
Thread 3 : Thread that is always running that receives and sends data to the
actual worker-threads
Thread 4 : Thread that is always running that receives and sends data to the
actual worker-threads
-----------
Thread 5 : Thread that is dynamically created by one of the Threads 1-4 and
which does a pit of processing.
Thread 6 : Thread that is dynamically created by one of the Threads 1-4 and
which does a pit of processing.
Thread 7 : Thread that is dynamically created by one of the Threads 1-4 and
which does a pit of processing.
Thread 8 : Thread that is dynamically created by one of the Threads 1-4 and
which does a pit of processing.
....
Thread X (or more) : Thread that is dynamically created by one of the
Threads 1-4 and which does a pit of processing.

(just FYI : the worker threads are not started and stopped very quickly, the
average lifetime of a thread is about 2-3 minutes, and they are only created
every 2-3 minutes)

Now comes the actual problem. Whenever Threads 5-X actually exit, they
always seem to interrupt the first 4 threads, IRRESPECTIVE of the
priorities. For instance, even if I have threads running at priority
TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
exit, the ultra-high priority threads get interrupted.

To give a concret example of just how dramtic this can be. If purely for
debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
actually exit, this sleep could last for as long as 150ms !!! But at no
other time does this occur.

Unfortunately for my purposes, the main threads being held off for up to
150seconds with absolutely no predictability is a very major problem! Does
anyone know why this could possibly be happening, or how to stop it ? Unless
I am missing something here, this would look like a rather serious problem
in NT time-slice sheduling !

(just FYI : I did DisableThreadLibraryCalls() on all the dlls that are being
loaded.)

Andrew Cross, Ph.D
Director of Software Development,
NewTek, www.newtek.com

 
 
 

Major problem with Win2000 and threads

Post by Luc Kump » Mon, 12 Mar 2001 18:34:37


NT is a non-realtime OS, but assuming that this is the only problem you
encountered, here's a possible approach.

I would propose to let the worker threads (5-x) live forever.
You could:
- create 2 event flags for each thread that you create: "Idle" and
"Activate". Both are auto-reset flags
- when the thread is finished, it sets the "Idle" eventflag, and
WaitForSingleObject(hActivateFlag). When the activate flag is set, the
worker thread starts working. The working threads look like this:

while(true)
  WaitForSingleObject(hActivate)
  ...do the work...
  SetEvent(hIdle)

- when one of the threads 1-4 wants to pass data to a working thread, it can
quickly find out which worker thread is idle by means of
WaitForMultipleObjects(hAllIdleFlags)

Eventually, you can wait with some timeout for a worker thread to become
available. Or if you want to go on as quickly as possible, you can specify a
timeout of 0.
If WFMO returns an object, you know which thread is free, and you can
  ResetEvent(hIdleOfFreeThread)
  SetEvent(hActivateOfFreeThread)
If WFMO returns a timeout, you can create a new worker thread.

Luc


Quote:> Hi All,

> I am writing a realtime processing system that runs under Windows2000. As
> time progresses within this system relatively large numbers of threads are
> routinely started and stopped as part of the process. There are a couple
of
> main threads that coordinate the whole thing and give data to the relevant
> processing threads ... To sum up the whole system as quickly as possible,
> imagine whats below

> Thread 1 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 2 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 3 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 4 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> -----------
> Thread 5 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 6 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 7 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 8 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> ....
> Thread X (or more) : Thread that is dynamically created by one of the
> Threads 1-4 and which does a pit of processing.

> (just FYI : the worker threads are not started and stopped very quickly,
the
> average lifetime of a thread is about 2-3 minutes, and they are only
created
> every 2-3 minutes)

> Now comes the actual problem. Whenever Threads 5-X actually exit, they
> always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> priorities. For instance, even if I have threads running at priority
> TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
> exit, the ultra-high priority threads get interrupted.

> To give a concret example of just how dramtic this can be. If purely for
> debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> actually exit, this sleep could last for as long as 150ms !!! But at no
> other time does this occur.

> Unfortunately for my purposes, the main threads being held off for up to
> 150seconds with absolutely no predictability is a very major problem! Does
> anyone know why this could possibly be happening, or how to stop it ?
Unless
> I am missing something here, this would look like a rather serious problem
> in NT time-slice sheduling !

> (just FYI : I did DisableThreadLibraryCalls() on all the dlls that are
being
> loaded.)

> Andrew Cross, Ph.D
> Director of Software Development,
> NewTek, www.newtek.com


 
 
 

Major problem with Win2000 and threads

Post by Ian McCoubre » Mon, 12 Mar 2001 21:51:16


Calling DisableThreadLibraryCalls()  for all the dlls being loaded is likely
to cause resource leaks. It should only be called by the dll itself, as per
the documentation.

You really need to use some form of thread pooling, as thread
creation/deletion isn't free. It almost certainly needs to acquire a process
wide lock, which could well interfere with the other threads in your
process.

Are threads 1-4 waiting for IO using completion ports?
Do they *always* start a new thread to handle the request, i.e. they never
handle it?

Ian.

--
-- Remove .no-spam from e-mail adress to reply

Quote:> Hi All,

> I am writing a realtime processing system that runs under Windows2000. As
> time progresses within this system relatively large numbers of threads are
> routinely started and stopped as part of the process. There are a couple
of
> main threads that coordinate the whole thing and give data to the relevant
> processing threads ... To sum up the whole system as quickly as possible,
> imagine whats below

> Thread 1 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 2 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 3 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> Thread 4 : Thread that is always running that receives and sends data to
the
> actual worker-threads
> -----------
> Thread 5 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 6 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 7 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> Thread 8 : Thread that is dynamically created by one of the Threads 1-4
and
> which does a pit of processing.
> ....
> Thread X (or more) : Thread that is dynamically created by one of the
> Threads 1-4 and which does a pit of processing.

> (just FYI : the worker threads are not started and stopped very quickly,
the
> average lifetime of a thread is about 2-3 minutes, and they are only
created
> every 2-3 minutes)

> Now comes the actual problem. Whenever Threads 5-X actually exit, they
> always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> priorities. For instance, even if I have threads running at priority
> TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
> exit, the ultra-high priority threads get interrupted.

> To give a concret example of just how dramtic this can be. If purely for
> debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> actually exit, this sleep could last for as long as 150ms !!! But at no
> other time does this occur.

> Unfortunately for my purposes, the main threads being held off for up to
> 150seconds with absolutely no predictability is a very major problem! Does
> anyone know why this could possibly be happening, or how to stop it ?
Unless
> I am missing something here, this would look like a rather serious problem
> in NT time-slice sheduling !

> (just FYI : I did DisableThreadLibraryCalls() on all the dlls that are
being
> loaded.)

> Andrew Cross, Ph.D
> Director of Software Development,
> NewTek, www.newtek.com

 
 
 

Major problem with Win2000 and threads

Post by Andrew Cros » Mon, 12 Mar 2001 21:02:13


First of all, thanks a lot for your reply. I really appreciate it.

Unfortunately, I cannot pool the threads because they are created by the
DirectShow API to read frames from video files and so are out of my control.
Basically speaking I am just trying to play video files back-to-back without
dropping frames ... which one would imagine that DirectShow should be
capable of. Because of the way DShow works I am obliged to shut down the
threads because otherwise they hand on to very significant ammounts of
memory (i.e. >1Mb per file I am trying to read from ... and in the kind of
application I am working on the user might well require 100-1000 different
clips !)


> Calling DisableThreadLibraryCalls()  for all the dlls being loaded is
likely
> to cause resource leaks. It should only be called by the dll itself, as
per
> the documentation.

> You really need to use some form of thread pooling, as thread
> creation/deletion isn't free. It almost certainly needs to acquire a
process
> wide lock, which could well interfere with the other threads in your
> process.

> Are threads 1-4 waiting for IO using completion ports?
> Do they *always* start a new thread to handle the request, i.e. they never
> handle it?

> Ian.

> --
> -- Remove .no-spam from e-mail adress to reply


> > Hi All,

> > I am writing a realtime processing system that runs under Windows2000.
As
> > time progresses within this system relatively large numbers of threads
are
> > routinely started and stopped as part of the process. There are a couple
> of
> > main threads that coordinate the whole thing and give data to the
relevant
> > processing threads ... To sum up the whole system as quickly as
possible,
> > imagine whats below

> > Thread 1 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 2 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 3 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 4 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > -----------
> > Thread 5 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 6 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 7 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 8 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > ....
> > Thread X (or more) : Thread that is dynamically created by one of the
> > Threads 1-4 and which does a pit of processing.

> > (just FYI : the worker threads are not started and stopped very quickly,
> the
> > average lifetime of a thread is about 2-3 minutes, and they are only
> created
> > every 2-3 minutes)

> > Now comes the actual problem. Whenever Threads 5-X actually exit, they
> > always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> > priorities. For instance, even if I have threads running at priority
> > TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
> > exit, the ultra-high priority threads get interrupted.

> > To give a concret example of just how dramtic this can be. If purely for
> > debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> > actually exit, this sleep could last for as long as 150ms !!! But at no
> > other time does this occur.

> > Unfortunately for my purposes, the main threads being held off for up to
> > 150seconds with absolutely no predictability is a very major problem!
Does
> > anyone know why this could possibly be happening, or how to stop it ?
> Unless
> > I am missing something here, this would look like a rather serious
problem
> > in NT time-slice sheduling !

> > (just FYI : I did DisableThreadLibraryCalls() on all the dlls that are
> being
> > loaded.)

> > Andrew Cross, Ph.D
> > Director of Software Development,
> > NewTek, www.newtek.com

 
 
 

Major problem with Win2000 and threads

Post by Andrew Cros » Mon, 12 Mar 2001 21:03:38


Luc, thanks a lot for your reply.

Unfortunately, I cannot pool the threads because they are created by the
DirectShow API to read frames from video files and so are out of my control.
Basically speaking I am just trying to play video files back-to-back without
dropping frames ... which one would imagine that DirectShow should be
capable of. Because of the way DShow works I am obliged to shut down the
threads because otherwise they keep their hand onto very significant
ammounts of memory (i.e. >1Mb per file I am trying to read from ... and in
the kind of application I am working on the user might well require 100-1000
different clips !)

This is quite a big problem considering that DShow is meant to replace the
old AVI reading and writing APIs.


> NT is a non-realtime OS, but assuming that this is the only problem you
> encountered, here's a possible approach.

> I would propose to let the worker threads (5-x) live forever.
> You could:
> - create 2 event flags for each thread that you create: "Idle" and
> "Activate". Both are auto-reset flags
> - when the thread is finished, it sets the "Idle" eventflag, and
> WaitForSingleObject(hActivateFlag). When the activate flag is set, the
> worker thread starts working. The working threads look like this:

> while(true)
>   WaitForSingleObject(hActivate)
>   ...do the work...
>   SetEvent(hIdle)

> - when one of the threads 1-4 wants to pass data to a working thread, it
can
> quickly find out which worker thread is idle by means of
> WaitForMultipleObjects(hAllIdleFlags)

> Eventually, you can wait with some timeout for a worker thread to become
> available. Or if you want to go on as quickly as possible, you can specify
a
> timeout of 0.
> If WFMO returns an object, you know which thread is free, and you can
>   ResetEvent(hIdleOfFreeThread)
>   SetEvent(hActivateOfFreeThread)
> If WFMO returns a timeout, you can create a new worker thread.

> Luc



> > Hi All,

> > I am writing a realtime processing system that runs under Windows2000.
As
> > time progresses within this system relatively large numbers of threads
are
> > routinely started and stopped as part of the process. There are a couple
> of
> > main threads that coordinate the whole thing and give data to the
relevant
> > processing threads ... To sum up the whole system as quickly as
possible,
> > imagine whats below

> > Thread 1 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 2 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 3 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > Thread 4 : Thread that is always running that receives and sends data to
> the
> > actual worker-threads
> > -----------
> > Thread 5 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 6 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 7 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > Thread 8 : Thread that is dynamically created by one of the Threads 1-4
> and
> > which does a pit of processing.
> > ....
> > Thread X (or more) : Thread that is dynamically created by one of the
> > Threads 1-4 and which does a pit of processing.

> > (just FYI : the worker threads are not started and stopped very quickly,
> the
> > average lifetime of a thread is about 2-3 minutes, and they are only
> created
> > every 2-3 minutes)

> > Now comes the actual problem. Whenever Threads 5-X actually exit, they
> > always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> > priorities. For instance, even if I have threads running at priority
> > TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
> > exit, the ultra-high priority threads get interrupted.

> > To give a concret example of just how dramtic this can be. If purely for
> > debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> > actually exit, this sleep could last for as long as 150ms !!! But at no
> > other time does this occur.

> > Unfortunately for my purposes, the main threads being held off for up to
> > 150seconds with absolutely no predictability is a very major problem!
Does
> > anyone know why this could possibly be happening, or how to stop it ?
> Unless
> > I am missing something here, this would look like a rather serious
problem
> > in NT time-slice sheduling !

> > (just FYI : I did DisableThreadLibraryCalls() on all the dlls that are
> being
> > loaded.)

> > Andrew Cross, Ph.D
> > Director of Software Development,
> > NewTek, www.newtek.com

 
 
 

Major problem with Win2000 and threads

Post by Kevin Pinkerto » Tue, 13 Mar 2001 04:14:21


Andrew, what about using a multi-processor machine for this
application? Is that an option? I have seen wonderful performance
increases using multi-processors. I am not a multi-thread expert, but
you can dictate which threads run on which processors. Maybe this
"pause" could be processed by the processor not running the 4 or 5
main threads.

Kevin

 
 
 

Major problem with Win2000 and threads

Post by Luc Kump » Tue, 13 Mar 2001 05:07:19


OK, next try ;^)
Would it be possible to create/destroy the threads in a different *process*,
running at Idle priority, with the time-critical threads would run in a
Time_Critical process?
E.g. passing data through named pipes?

Luc


> Luc, thanks a lot for your reply.

> Unfortunately, I cannot pool the threads because they are created by the
> DirectShow API to read frames from video files and so are out of my
control.
> Basically speaking I am just trying to play video files back-to-back
without
> dropping frames ... which one would imagine that DirectShow should be
> capable of. Because of the way DShow works I am obliged to shut down the
> threads because otherwise they keep their hand onto very significant
> ammounts of memory (i.e. >1Mb per file I am trying to read from ... and in
> the kind of application I am working on the user might well require
100-1000
> different clips !)

> This is quite a big problem considering that DShow is meant to replace the
> old AVI reading and writing APIs.



> > NT is a non-realtime OS, but assuming that this is the only problem you
> > encountered, here's a possible approach.

> > I would propose to let the worker threads (5-x) live forever.
> > You could:
> > - create 2 event flags for each thread that you create: "Idle" and
> > "Activate". Both are auto-reset flags
> > - when the thread is finished, it sets the "Idle" eventflag, and
> > WaitForSingleObject(hActivateFlag). When the activate flag is set, the
> > worker thread starts working. The working threads look like this:

> > while(true)
> >   WaitForSingleObject(hActivate)
> >   ...do the work...
> >   SetEvent(hIdle)

> > - when one of the threads 1-4 wants to pass data to a working thread, it
> can
> > quickly find out which worker thread is idle by means of
> > WaitForMultipleObjects(hAllIdleFlags)

> > Eventually, you can wait with some timeout for a worker thread to become
> > available. Or if you want to go on as quickly as possible, you can
specify
> a
> > timeout of 0.
> > If WFMO returns an object, you know which thread is free, and you can
> >   ResetEvent(hIdleOfFreeThread)
> >   SetEvent(hActivateOfFreeThread)
> > If WFMO returns a timeout, you can create a new worker thread.

> > Luc



> > > Hi All,

> > > I am writing a realtime processing system that runs under Windows2000.
> As
> > > time progresses within this system relatively large numbers of threads
> are
> > > routinely started and stopped as part of the process. There are a
couple
> > of
> > > main threads that coordinate the whole thing and give data to the
> relevant
> > > processing threads ... To sum up the whole system as quickly as
> possible,
> > > imagine whats below

> > > Thread 1 : Thread that is always running that receives and sends data
to
> > the
> > > actual worker-threads
> > > Thread 2 : Thread that is always running that receives and sends data
to
> > the
> > > actual worker-threads
> > > Thread 3 : Thread that is always running that receives and sends data
to
> > the
> > > actual worker-threads
> > > Thread 4 : Thread that is always running that receives and sends data
to
> > the
> > > actual worker-threads
> > > -----------
> > > Thread 5 : Thread that is dynamically created by one of the Threads
1-4
> > and
> > > which does a pit of processing.
> > > Thread 6 : Thread that is dynamically created by one of the Threads
1-4
> > and
> > > which does a pit of processing.
> > > Thread 7 : Thread that is dynamically created by one of the Threads
1-4
> > and
> > > which does a pit of processing.
> > > Thread 8 : Thread that is dynamically created by one of the Threads
1-4
> > and
> > > which does a pit of processing.
> > > ....
> > > Thread X (or more) : Thread that is dynamically created by one of the
> > > Threads 1-4 and which does a pit of processing.

> > > (just FYI : the worker threads are not started and stopped very
quickly,
> > the
> > > average lifetime of a thread is about 2-3 minutes, and they are only
> > created
> > > every 2-3 minutes)

> > > Now comes the actual problem. Whenever Threads 5-X actually exit, they
> > > always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> > > priorities. For instance, even if I have threads running at priority
> > > TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads
5-X
> > > exit, the ultra-high priority threads get interrupted.

> > > To give a concret example of just how dramtic this can be. If purely
for
> > > debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> > > actually exit, this sleep could last for as long as 150ms !!! But at
no
> > > other time does this occur.

> > > Unfortunately for my purposes, the main threads being held off for up
to
> > > 150seconds with absolutely no predictability is a very major problem!
> Does
> > > anyone know why this could possibly be happening, or how to stop it ?
> > Unless
> > > I am missing something here, this would look like a rather serious
> problem
> > > in NT time-slice sheduling !

> > > (just FYI : I did DisableThreadLibraryCalls() on all the dlls that are
> > being
> > > loaded.)

> > > Andrew Cross, Ph.D
> > > Director of Software Development,
> > > NewTek, www.newtek.com

 
 
 

Major problem with Win2000 and threads

Post by Andrew Cros » Tue, 13 Mar 2001 06:03:22


Kevin,

Thanks a lot for your reply. I am actually already running on a multi-CPU
machine, however something I have not tried yet is to 'move' all the threads
that are terminating to a single CPU and keeping the others on the other
CPU.

Andrew


Quote:> Andrew, what about using a multi-processor machine for this
> application? Is that an option? I have seen wonderful performance
> increases using multi-processors. I am not a multi-thread expert, but
> you can dictate which threads run on which processors. Maybe this
> "pause" could be processed by the processor not running the 4 or 5
> main threads.

> Kevin

 
 
 

Major problem with Win2000 and threads

Post by Andrew Cros » Tue, 13 Mar 2001 00:07:58


Unfortunately I am already using a multi-cpu machine ... It seems that
threads exiting block everything else in the same process.


Quote:> Andrew, what about using a multi-processor machine for this
> application? Is that an option? I have seen wonderful performance
> increases using multi-processors. I am not a multi-thread expert, but
> you can dictate which threads run on which processors. Maybe this
> "pause" could be processed by the processor not running the 4 or 5
> main threads.

> Kevin

 
 
 

Major problem with Win2000 and threads

Post by Andrew Cros » Tue, 13 Mar 2001 00:07:24


Thats the idea that I am currently working on ... I would have to use
memory-mapped files to transfer the data because the ammount of data is very
large (uncompressed video frames) ... I am sure that I am still going to run
into some problems, but this is probably the only way to go.

It's very dissapointing that Windows does not handle something relatively
basic like clean creation and deletion of threads better.

Quote:> OK, next try ;^)
> Would it be possible to create/destroy the threads in a different
*process*,
> running at Idle priority, with the time-critical threads would run in a
> Time_Critical process?
> E.g. passing data through named pipes?

> Luc

 
 
 

Major problem with Win2000 and threads

Post by michk » Tue, 13 Mar 2001 06:56:15



Quote:> It's very dissapointing that Windows does not handle something relatively
> basic like clean creation and deletion of threads better.

32 bit Windows is not and has never been a realtime OS. It is easy to find
yourself disappointed when you have unrealistic expectations...

Perhaps an analogy would help: I also find it very disappointing that I
could not breathe if I were on the moon.... I mean, is it not disappointing
that something basic like *breathing* does not work better on a planet or
sattelite with no air?

Windows DOES handle creation and deletion of threads very well for what it
is supposed to do. You just have to work with the architecture.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

 
 
 

Major problem with Win2000 and threads

Post by Luc Kump » Tue, 13 Mar 2001 17:16:11



Quote:> require a special OS to run on, and indeed is one of the target markets
for
> Windows (Professional graphics and video, hence the original inclusion of
> APIs like OpenGL.) In a video application you need to send a constant
stream
> of frames to the output at a rate of about 33ms. So any kind of
non-realtime
> delays that fall much below that are thoroughly acceptable, and noone is
> claiming that there should be no delay, yet I am seeing delays of almost
> 150ms !

Does this rate of 33ms need to be handled by a user application, without any
hardware capable of buffering a few frames? While you might get this to work
on a *specific* PC, I can't believe you'll get it to work reliably on *any*
PC. IMHO, there are too many "unknows" that could steal cycles away from
your application: LAN interfaces, printer drivers, mouse movements, ...
You'll get random delays from all of these, and sometimes the different
delays will add up to something large...

Luc

 
 
 

Major problem with Win2000 and threads

Post by Slava M. Uso » Tue, 13 Mar 2001 18:15:19



[...]

Quote:> Now comes the actual problem. Whenever Threads 5-X actually exit, they
> always seem to interrupt the first 4 threads, IRRESPECTIVE of the
> priorities. For instance, even if I have threads running at priority
> TIME_CRITICAL, and Threads 5-X running at IDLE then when the threads 5-X
> exit, the ultra-high priority threads get interrupted.

> To give a concret example of just how dramtic this can be. If purely for
> debugging purposes, I put a Sleep(10) in Threads 1-4, when Threads 5-X
> actually exit, this sleep could last for as long as 150ms !!! But at no
> other time does this occur.

That might be due to Sleep()'s giving the rest of the quantum to another
thread... As explained at

http://www.sysinternals.com/ntw2k/info/nt5.shtml

on an SMP [which you said you were using] W2K quantum may vary anywhere
between 90 ms and 540 ms; and 150 ms that you saw happens only because it's
just enough time for a thread to rundown and exit.

Try larger sleep value, such as 30 ms, that might improve things [10 ms is
less than the time slice on SMP platforms, so it may well be ignored].

Slava

 
 
 

Major problem with Win2000 and threads

Post by Dan Wandere » Tue, 13 Mar 2001 23:47:34


Just my $0.02  ;)

This sentence jogged my memory

Quote:>Because of the way DShow works I am obliged to shut down the
>threads because otherwise they keep their hand onto very significant
>ammounts of memory (i.e. >1Mb per file I am trying to read from

because I recall a question recently about 'why is the Win2k heap
manager so slow'

Is it possible that the 150ms delay is caused when the threads release
the memory they allocated?

If so, AND you could override their heap allocation with your own,
maybe you could reduce their exit time.

I know, lots of if's and maybe's, but who knows?

    Dan

 
 
 

1. RPC (and general, major Win2000) failure after installation of 3rd party control

Hi,

After installing a new business app and then 3rd-party control
(ChartFX Client Server), my RPC Service will no longer start.  I get
error messages opening new (blank) documents in Word and Excel.
Visual Studio 6 works with mixed success (VC++ will open; VB won't
open at all; Visual InterDev opens with an error message).  Opening
Add/Remove Programs in the Control Panel presents me with a completely
blank screen.  Javascript doesn't work in IE6, even though Internet
Options are set so it should.

Basic Windows functionality is gone (I can't search for files, or
cut/copy/paste files *or* text).  Fortunately, I still remember my DOS
commands, because that's still working...

I'm running Win2000 Server, v 5 (Build 2195, Service Pack 2).

I was running Norton Antivirus and getting a NAV alert about RPC, but
uninstalled NAV after reading this post:

http://groups.google.com/groups?hl=en&threadm=Gku84.238%24G_6.15377%40ne
  ws.uswest.net&rnum=1&prev=/groups%3Fq%3Derror%2Bstarting%2BRPC%2BServer%
  26hl%3Den%26selm%3DGku84.238%2524G_6.15377%2540news.uswest.net%26rnum%3D
  1

Basically, I'm at the "HELP!" stage, so any thoughts on what I can do
short of reinstalling Windows would be appreciated.

I have posted to the ChartFX newsgroup to see if anyone has
encountered this problem.

Thanks,
Anne Massard

2. Velocity Engine

3. Row Major versus Column Major Initialization

4. QUESTIONS

5. row major/col major matrix

6. Open Rate//Java Developers 7 positions //Long term contract in DE //Direct Client

7. Where can I find posted test results of threading times for most major OS's?

8. FS: Star NX 1020 color printer & Boca 14.4

9. NTB3, /Win2000 Professional, Win2000 Server

10. Windows 95 DUN - Major SMM PROBLEM

11. major tapi3 problems

12. major pthreads problem

13. Major Problem!! with Spawn