Do threads behave Differently on Windows 98?

[Codemonkey]

Hi,

Sorry for the cross group post, but I couldn't find a group that deals with
threading in .net.

Anyway, I've noticed a difference in the way my program acts on Windows 98
than it does on WindowsXP and was wondering if anybody can explain this
behaviour.

My application runs in the background to collect data through the serial
port using a 3rd party ActiveX communications control (not MSComm). The
control is single threaded and needs a form to be hosted on. I call the
"Read" method on the control to read data and the result is returned
Asynchronously in an event called "OnReadDone".

I host the control on a hidden form that is created on an STA thread. When I
want to read data, I invoke the "ReadSync" method on the form (which I have
created to convert the Asynchronous "Read" call to a synchronous call). I
use a ManualResetEvent in the "ReadSync" method to block the thread until
the result is returned by the event.

In Windows XP, everything works fine - the "ReadSync" method blocks, the
event fires, and then the "ReadSync" method returns.

In Windows 98, the event doesn't fire until the wait on the ManualResetEvent
times out and unblocks the form's thread.

I've fixed the problem by not ever blocking the form's thread - by moving
the "ReadSync" method into the thread that invokes the "Read" method and
waiting there.

Is this behaviour by design and is Windows XP letting me do things I
shouldn't be, or is it a shortcoming in the way threads are handled under
Windows 98? Could it be something to do with the COM interop side of things
with the ActiveX control?

I'm using Visual Studio 2003 and Framework 1.1 on both machines.

I'd appreciate any thoughts on this.

Best Regards,

Trev.

 

[Ying-Shen Yu[MSFT]]

Hi,
Thanks for your post!
I'd like to how did you set the signal to your ManualResetEvent?
On Windows98 system, was the ManualResetEvent.Set method be executed
before the Wait method timeout?
I have another question, does this problem also occur when you using the
ActiveX control in VB6?
I'd like to check if it is an COM/Interop problem or an event/thread
problem.

Thanks for you help!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
You should not reply this mail directly, "Online" should be removed before
sending, Thanks!

--------------------
| From: "Codemonkey" <[email protected]>
| Subject: Do threads behave Differently on Windows 98?
| Date: Wed, 29 Oct 2003 16:46:41 -0000
| Lines: 45
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <[email protected]>
| Newsgroups:
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework.interop,micro
soft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general
| NNTP-Posting-Host: prtn-3e352849.pool.mediaways.net 62.53.40.73
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
| Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.interop:20000
microsoft.public.dotnet.framework.windowsforms:55447
microsoft.public.dotnet.general:113579 microsoft.public.dotnet.faqs:12218
| X-Tomcat-NG: microsoft.public.dotnet.framework.windowsforms
|
| Hi,
|
| Sorry for the cross group post, but I couldn't find a group that deals
with
| threading in .net.
|
| Anyway, I've noticed a difference in the way my program acts on Windows 98
| than it does on WindowsXP and was wondering if anybody can explain this
| behaviour.
|
| My application runs in the background to collect data through the serial
| port using a 3rd party ActiveX communications control (not MSComm). The
| control is single threaded and needs a form to be hosted on. I call the
| "Read" method on the control to read data and the result is returned
| Asynchronously in an event called "OnReadDone".
|
| I host the control on a hidden form that is created on an STA thread.
When I
| want to read data, I invoke the "ReadSync" method on the form (which I
have
| created to convert the Asynchronous "Read" call to a synchronous call). I
| use a ManualResetEvent in the "ReadSync" method to block the thread until
| the result is returned by the event.
|
| In Windows XP, everything works fine - the "ReadSync" method blocks, the
| event fires, and then the "ReadSync" method returns.
|
| In Windows 98, the event doesn't fire until the wait on the
ManualResetEvent
| times out and unblocks the form's thread.
|
| I've fixed the problem by not ever blocking the form's thread - by moving
| the "ReadSync" method into the thread that invokes the "Read" method and
| waiting there.
|
| Is this behaviour by design and is Windows XP letting me do things I
| shouldn't be, or is it a shortcoming in the way threads are handled under
| Windows 98? Could it be something to do with the COM interop side of
things
| with the ActiveX control?
|
| I'm using Visual Studio 2003 and Framework 1.1 on both machines.
|
| I'd appreciate any thoughts on this.
|
| Best Regards,
|
| Trev.
|
|
|

 

[Codemonkey]

Hi,

Thanks for your reply. I've spent a bit of time investigating this a further
by taking the 3rd party ActiveX out of the equasion and it seems to behave
as it should. It looks like the 3rd party ActiveX behaves differently on
Windows 98, not the interop or threads.

Sorry for the false alarm and wasted time.


To answer to your other questions:

I'd like to how did you set the signal to your ManualResetEvent?

I call the "Read" method on the control then I call
ManualResetEvent.WaitOne. The control then fires the "OnReadDone" event
which calls the ManualResetEvent.Set.

On Windows98 system, was the ManualResetEvent.Set method be executed
before the Wait method timeout?

On the Windows 98 system, the "OnReadDone" event wasn't firing until after
the timeout. On the Windows XP system, it was firing before the timeout.

As far as I can tell, the behaviour on Windows 98 is correct - if the form's
thread is blocked, events from controls cannot be handled until the thread
is unblocked. Somehow, the 3rd party control must be raising the event on
another thread under Windows XP (I have checked this in the debugger, but it
reports that the event is fired on the same thread - pretty confusing).

I've corrected my code by not blocking the Form's thread with the
ManualResetEvent, instead I block the calling thread and wait for a callback
from the form.

I have another question, does this problem also occur when you using the
ActiveX control in VB6?

In VB6 I used a DoEvents and WaitMessage() loop to block the method until
the event was raised, not threads, as a result this problem didn't appear.


Thanks again for your help,

Trev.

Hi,
Thanks for your post!
I'd like to how did you set the signal to your ManualResetEvent?
On Windows98 system, was the ManualResetEvent.Set method be executed
before the Wait method timeout?
I have another question, does this problem also occur when you using the
ActiveX control in VB6?
I'd like to check if it is an COM/Interop problem or an event/thread
problem.

Thanks for you help!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
You should not reply this mail directly, "Online" should be removed before
sending, Thanks!

--------------------
| From: "Codemonkey" <[email protected]>
| Subject: Do threads behave Differently on Windows 98?
| Date: Wed, 29 Oct 2003 16:46:41 -0000
| Lines: 45
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <[email protected]>
| Newsgroups:
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework.interop,micro
soft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general
| NNTP-Posting-Host: prtn-3e352849.pool.mediaways.net 62.53.40.73
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
| Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.interop:20000
microsoft.public.dotnet.framework.windowsforms:55447
microsoft.public.dotnet.general:113579 microsoft.public.dotnet.faqs:12218
| X-Tomcat-NG: microsoft.public.dotnet.framework.windowsforms
|
| Hi,
|
| Sorry for the cross group post, but I couldn't find a group that deals
with
| threading in .net.
|
| Anyway, I've noticed a difference in the way my program acts on Windows 98
| than it does on WindowsXP and was wondering if anybody can explain this
| behaviour.
|
| My application runs in the background to collect data through the serial
| port using a 3rd party ActiveX communications control (not MSComm). The
| control is single threaded and needs a form to be hosted on. I call the
| "Read" method on the control to read data and the result is returned
| Asynchronously in an event called "OnReadDone".
|
| I host the control on a hidden form that is created on an STA thread.
When I
| want to read data, I invoke the "ReadSync" method on the form (which I
have
| created to convert the Asynchronous "Read" call to a synchronous call). I
| use a ManualResetEvent in the "ReadSync" method to block the thread until
| the result is returned by the event.
|
| In Windows XP, everything works fine - the "ReadSync" method blocks, the
| event fires, and then the "ReadSync" method returns.
|
| In Windows 98, the event doesn't fire until the wait on the
ManualResetEvent
| times out and unblocks the form's thread.
|
| I've fixed the problem by not ever blocking the form's thread - by moving
| the "ReadSync" method into the thread that invokes the "Read" method and
| waiting there.
|
| Is this behaviour by design and is Windows XP letting me do things I
| shouldn't be, or is it a shortcoming in the way threads are handled under
| Windows 98? Could it be something to do with the COM interop side of
things
| with the ActiveX control?
|
| I'm using Visual Studio 2003 and Framework 1.1 on both machines.
|
| I'd appreciate any thoughts on this.
|
| Best Regards,
|
| Trev.
|
|
|

 

[William Armstrong]

One thing to bear in mind when your main form is receiving events from other
threads, is to check the InvokeRequired property of the form before you do
anything with the form's controls.

This may or may not be the cause of your problem, but it's worth doing
anyway. You can run your app without ever seeing any errors while testing,
but eventually you will get an error if you don't use Invoke to get the call
back onto your form's own thread. This can make it hard to track down what
actually went wrong, due to the intermittent nature of errors caused by
this.

 

[Codemonkey]

Yeah, I know the pitfalls of multithreaded forms all to well and have gotten
into the habit of using Invoke whenever it is remotely possible that another
thread is involved.

However, in this case it's different - the form exists on one thread and my
"SyncRead" method is called using Invoke from another thread. The behaviour
I've mentioned all takes place in the form's own thread. At the minute I'm
99% sure that it's the third party control that behaves differently on
Windows 98 than it does on Windows XP.

Thanks for the help.

Trev.