Driver calls vs graphics mutex vs Ethernet card

I am currently debugging a multithreaded application where one thread (the
"Render" thread) is using the display driver (i.e. through ExtEscape calls).
The system is a dual CPU Windows 2000 system (SP2), with two displays (i.e.
two display drivers); the application is using the secondary display only.
The Render thread is running at real-time priority (i.e. priority 29).

I have a strange problem where once in a while, an ExtEscape call to the
display driver (e.g. some custom escape function)
takes _way_ too much time (ex: 12msec). After thorough debugging, I know
that my application thread is preempted just when it calls ExtEscape, as if
Windows was serializing accesses to the display driver (some global graphics
mutex?). It is not a matter of "quantum completion" because my thread is at
priority 29 and I also know that the Window's scheduler usually schedule the
Idle thread during these 12msec.

What is also very strange, is that when this 12msec "glitch" occurs with the
Render thread, my other thread (which is running
simultaneously on the other CPU), suffers from the same glitch too. After
debugging, I know that no thread switch occurs on this CPU, which means that
this thread is simply stopped for 12msec (maybe by an interrupt from some
device?)

To summarize, I have no clue what is going on. My first theory is that an
interrupt is stopping my second thread, and the ISR (or DPC) is doing
something that uses some mutex that will (in some cases) make the Render
thread wait before it can talk to its display driver. But I can not see what
it could be. Is there something special regarding how Windows serializes
display driver accesses that I should know? Something special with multiple
displays? Hardware interrupts that would use the display driver?

Note: We noticed that this problem disappears when we disconnect our
Ethernet card from the network. Our Ethernet chipset
(Intel) is transferring data in DMA to the system memory, and our driver
accesses it by polling only: there is no interrupt used by the driver. When
disconnected, there is no more DMA transfer being done (I assume) but we
keep polling the driver without never getting any packet. Of course, we need
to be connected to the network, so disconnecting is not a viable solution


Any help is welcome,
Thanks,

Ozo

have you tried streaming the data from the hdd instead of the ethernet ?

--
Louis Solomon
<a style='text-decoration: underline;' href="http://www.steelbytes.com" target="_blank">www.steelbytes.com</a>

"Ozo" <ozo.TakeThisOut@whoever.com> wrote in message
news:Go8Cb.10267$aF2.1141896@news20.bellglobal.com...
 >I am currently debugging a multithreaded application where one thread (the
 > "Render" thread) is using the display driver (i.e. through ExtEscape
 > calls).
 > The system is a dual CPU Windows 2000 system (SP2), with two displays
 > (i.e.
 > two display drivers); the application is using the secondary display only.
 > The Render thread is running at real-time priority (i.e. priority 29).
 >
 > I have a strange problem where once in a while, an ExtEscape call to the
 > display driver (e.g. some custom escape function)
 > takes _way_ too much time (ex: 12msec). After thorough debugging, I know
 > that my application thread is preempted just when it calls ExtEscape, as
 > if
 > Windows was serializing accesses to the display driver (some global
 > graphics
 > mutex?). It is not a matter of "quantum completion" because my thread is
 > at
 > priority 29 and I also know that the Window's scheduler usually schedule
 > the
 > Idle thread during these 12msec.
 >
 > What is also very strange, is that when this 12msec "glitch" occurs with
 > the
 > Render thread, my other thread (which is running
 > simultaneously on the other CPU), suffers from the same glitch too. After
 > debugging, I know that no thread switch occurs on this CPU, which means
 > that
 > this thread is simply stopped for 12msec (maybe by an interrupt from some
 > device?)
 >
 > To summarize, I have no clue what is going on. My first theory is that an
 > interrupt is stopping my second thread, and the ISR (or DPC) is doing
 > something that uses some mutex that will (in some cases) make the Render
 > thread wait before it can talk to its display driver. But I can not see
 > what
 > it could be. Is there something special regarding how Windows serializes
 > display driver accesses that I should know? Something special with
 > multiple
 > displays? Hardware interrupts that would use the display driver?
 >
 > Note: We noticed that this problem disappears when we disconnect our
 > Ethernet card from the network. Our Ethernet chipset
 > (Intel) is transferring data in DMA to the system memory, and our driver
 > accesses it by polling only: there is no interrupt used by the driver.
 > When
 > disconnected, there is no more DMA transfer being done (I assume) but we
 > keep polling the driver without never getting any packet. Of course, we
 > need
 > to be connected to the network, so disconnecting is not a viable solution
 >
 >
 > Any help is welcome,
 > Thanks,
 >
 > Ozo
 >
 ><!-- ~MESSAGE_AFTER~ -->