Driver calls vs graphics mutex vs Ethernet card

[Ozo]

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

[Louis Solomon [SteelBytes]]

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

--
Louis Solomon
www.steelbytes.com

"Ozo" <ozo@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