Hi,

I’ve written a C# console app that does a lot of things simultaneously. The
device being used is an FB6500 (http://www.fabiatech.com/products/fb6500.htm)
running Windows CE 5.0. These are all the things the app does:

1. Uses four threads to scan four COM ports – each port processes real time
data composed of packets. These packets are on average 25 bytes long and
throughput is around 15 packets/sec. So all ports combined process 60
packets/sec.

2. Opens two network sockets – 1 for sending data and another for receiving.
The receiving socket listens for incoming commands from a connected client.

3. Uses 3 timers – one which runs every 10 seconds sends 1500 bytes of data
through a socket to a connected client, another which runs every minute
checks the status of certain variables, and the third runs every hour and
uses RDA (remote data access) to synchronize a remote SQL Server 2000
database.

4. Keeps a log of things that may happen by keeping a file open and writing
to it when necessary.

I also need to run a client on a desktop PC which connects to the listening
socket of the app on the device. This client simply receives the 1500 bytes
of data every ten seconds and updates a form. When running the app on the
device, it works fine functionally but I have noticed that a lot of times the
console app freezes after a while (the mouse is still movable but I can’t
press anything, the system time at the bottom right corner also freezes). I
ran it overnight last night and this morning when I checked it, it was still
running. I then ran it again and after 20 mins or so it freezes. The amount
of time it takes until it freezes is unpredictable. The funny thing is when
running it under VS.NET debug mode, after the app freezes, the serial
processing is still taking place, it’s the networking stuff that’s stopped
(i.e. the client no longer receives the 1500 bytes every ten secs). Would the
number of threads running cause this freezing to take place? I honestly don’t
know where to begin to fix this problem. My app NEEDS to run for long periods
of time (i.e. over 12 hours). Can anyone shed any light on what might be
causing this or where I should start looking? Thanks in advance.

Kind Regards,

Michael--J

You probably have a race condition somewhere; this is the common reason for
multithreaded applications to hang.

Make sure all shared (between threads) objects are properly locked/unlocked.



Best regards,



Ilya



This posting is provided "AS IS" with no warranties, and confers no rights.


"Michael--J" <(E-Mail Removed)> wrote in message
news:2A88D523-2302-4891-943E-(E-Mail Removed)...
> Hi,
>
> I've written a C# console app that does a lot of things simultaneously.
> The
> device being used is an FB6500
> (http://www.fabiatech.com/products/fb6500.htm)
> running Windows CE 5.0. These are all the things the app does:
>
> 1. Uses four threads to scan four COM ports - each port processes real
> time
> data composed of packets. These packets are on average 25 bytes long and
> throughput is around 15 packets/sec. So all ports combined process 60
> packets/sec.
>
> 2. Opens two network sockets - 1 for sending data and another for
> receiving.
> The receiving socket listens for incoming commands from a connected
> client.
>
> 3. Uses 3 timers - one which runs every 10 seconds sends 1500 bytes of
> data
> through a socket to a connected client, another which runs every minute
> checks the status of certain variables, and the third runs every hour and
> uses RDA (remote data access) to synchronize a remote SQL Server 2000
> database.
>
> 4. Keeps a log of things that may happen by keeping a file open and
> writing
> to it when necessary.
>
> I also need to run a client on a desktop PC which connects to the
> listening
> socket of the app on the device. This client simply receives the 1500
> bytes
> of data every ten seconds and updates a form. When running the app on the
> device, it works fine functionally but I have noticed that a lot of times
> the
> console app freezes after a while (the mouse is still movable but I can't
> press anything, the system time at the bottom right corner also freezes).
> I
> ran it overnight last night and this morning when I checked it, it was
> still
> running. I then ran it again and after 20 mins or so it freezes. The
> amount
> of time it takes until it freezes is unpredictable. The funny thing is
> when
> running it under VS.NET debug mode, after the app freezes, the serial
> processing is still taking place, it's the networking stuff that's stopped
> (i.e. the client no longer receives the 1500 bytes every ten secs). Would
> the
> number of threads running cause this freezing to take place? I honestly
> don't
> know where to begin to fix this problem. My app NEEDS to run for long
> periods
> of time (i.e. over 12 hours). Can anyone shed any light on what might be
> causing this or where I should start looking? Thanks in advance.
>
> Kind Regards,
>
> Michael--J

Thanks for your quick reply. I see what you are getting at. But how would a
race condition cause a hang? I thought it usually just corrupts the proper
value of an object or variable.

I'm getting quite worried because i have been working on this app for quite
some time now and to find out it can't last for long periods of time is
really disappointing. I just want to make sure whether things like this are
fixable or if it's inherent with running multithreaded apps on
resource-contrained devices. It's just very wierd that sometimes it runs for
hours (it ran for 10 hours once) and at other times it freezes after 20, or
30 mins or so. I'll have a look and see if i can find any race conditions.
Thanks in advance.

Michael--J.

"Ilya Tumanov [MS]" wrote:

> You probably have a race condition somewhere; this is the common reason for
> multithreaded applications to hang.
>
> Make sure all shared (between threads) objects are properly locked/unlocked.
>
>
>
> Best regards,
>
>
>
> Ilya
>
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Michael--J" <(E-Mail Removed)> wrote in message
> news:2A88D523-2302-4891-943E-(E-Mail Removed)...
> > Hi,
> >
> > I've written a C# console app that does a lot of things simultaneously.
> > The
> > device being used is an FB6500
> > (http://www.fabiatech.com/products/fb6500.htm)
> > running Windows CE 5.0. These are all the things the app does:
> >
> > 1. Uses four threads to scan four COM ports - each port processes real
> > time
> > data composed of packets. These packets are on average 25 bytes long and
> > throughput is around 15 packets/sec. So all ports combined process 60
> > packets/sec.
> >
> > 2. Opens two network sockets - 1 for sending data and another for
> > receiving.
> > The receiving socket listens for incoming commands from a connected
> > client.
> >
> > 3. Uses 3 timers - one which runs every 10 seconds sends 1500 bytes of
> > data
> > through a socket to a connected client, another which runs every minute
> > checks the status of certain variables, and the third runs every hour and
> > uses RDA (remote data access) to synchronize a remote SQL Server 2000
> > database.
> >
> > 4. Keeps a log of things that may happen by keeping a file open and
> > writing
> > to it when necessary.
> >
> > I also need to run a client on a desktop PC which connects to the
> > listening
> > socket of the app on the device. This client simply receives the 1500
> > bytes
> > of data every ten seconds and updates a form. When running the app on the
> > device, it works fine functionally but I have noticed that a lot of times
> > the
> > console app freezes after a while (the mouse is still movable but I can't
> > press anything, the system time at the bottom right corner also freezes).
> > I
> > ran it overnight last night and this morning when I checked it, it was
> > still
> > running. I then ran it again and after 20 mins or so it freezes. The
> > amount
> > of time it takes until it freezes is unpredictable. The funny thing is
> > when
> > running it under VS.NET debug mode, after the app freezes, the serial
> > processing is still taking place, it's the networking stuff that's stopped
> > (i.e. the client no longer receives the 1500 bytes every ten secs). Would
> > the
> > number of threads running cause this freezing to take place? I honestly
> > don't
> > know where to begin to fix this problem. My app NEEDS to run for long
> > periods
> > of time (i.e. over 12 hours). Can anyone shed any light on what might be
> > causing this or where I should start looking? Thanks in advance.
> >
> > Kind Regards,
> >
> > Michael--J
>
>
>

If something's corrupted, anything could happen.
May be, you have a loop you could never leave because another thread
messing with loop counter.
Or, may be, you have a classical deadlock. Whatever the reason, it is
fixable.

Just carefully identify all shared objects and add locking if these objects
are not thread safe.

If you're using some sort of custom semaphores (not the lock statement),
don't forget to unlock objects even if you have an exception.
You might use finally blocks to do so.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
> Thread-Topic: Console app freezes
> thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
> X-WBNR-Posting-Host: 211.26.115.247
> From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <(E-Mail Removed)>
> References: <2A88D523-2302-4891-943E-(E-Mail Removed)>
<41c11d2a$(E-Mail Removed)>
> Subject: Re: Console app freezes
> Date: Thu, 16 Dec 2004 03:17:08 -0800
> Lines: 100
> Message-ID: <BE00D6F5-A077-47D8-9C4A-(E-Mail Removed)>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="Utf-8"
> Content-Transfer-Encoding: 7bit
> X-Newsreader: Microsoft CDO for Windows 2000
> Content-Class: urn:content-classes:message
> Importance: normal
> Priority: normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> Newsgroups: microsoft.public.dotnet.framework.compactframework
> NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67045
> X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
>
> Thanks for your quick reply. I see what you are getting at. But how would
a
> race condition cause a hang? I thought it usually just corrupts the
proper
> value of an object or variable.
>
> I'm getting quite worried because i have been working on this app for
quite
> some time now and to find out it can't last for long periods of time is
> really disappointing. I just want to make sure whether things like this
are
> fixable or if it's inherent with running multithreaded apps on
> resource-contrained devices. It's just very wierd that sometimes it runs
for
> hours (it ran for 10 hours once) and at other times it freezes after 20,
or
> 30 mins or so. I'll have a look and see if i can find any race
conditions.
> Thanks in advance.
>
> Michael--J.
>
> "Ilya Tumanov [MS]" wrote:
>
> > You probably have a race condition somewhere; this is the common reason
for
> > multithreaded applications to hang.
> >
> > Make sure all shared (between threads) objects are properly
locked/unlocked.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Ilya
> >
> >
> >
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> >
> > "Michael--J" <(E-Mail Removed)> wrote in message
> > news:2A88D523-2302-4891-943E-(E-Mail Removed)...
> > > Hi,
> > >
> > > I've written a C# console app that does a lot of things
simultaneously.
> > > The
> > > device being used is an FB6500
> > > (http://www.fabiatech.com/products/fb6500.htm)
> > > running Windows CE 5.0. These are all the things the app does:
> > >
> > > 1. Uses four threads to scan four COM ports - each port processes
real
> > > time
> > > data composed of packets. These packets are on average 25 bytes long
and
> > > throughput is around 15 packets/sec. So all ports combined process 60
> > > packets/sec.
> > >
> > > 2. Opens two network sockets - 1 for sending data and another for
> > > receiving.
> > > The receiving socket listens for incoming commands from a connected
> > > client.
> > >
> > > 3. Uses 3 timers - one which runs every 10 seconds sends 1500 bytes
of
> > > data
> > > through a socket to a connected client, another which runs every
minute
> > > checks the status of certain variables, and the third runs every hour
and
> > > uses RDA (remote data access) to synchronize a remote SQL Server 2000
> > > database.
> > >
> > > 4. Keeps a log of things that may happen by keeping a file open and
> > > writing
> > > to it when necessary.
> > >
> > > I also need to run a client on a desktop PC which connects to the
> > > listening
> > > socket of the app on the device. This client simply receives the 1500
> > > bytes
> > > of data every ten seconds and updates a form. When running the app on
the
> > > device, it works fine functionally but I have noticed that a lot of
times
> > > the
> > > console app freezes after a while (the mouse is still movable but I
can't
> > > press anything, the system time at the bottom right corner also
freezes).
> > > I
> > > ran it overnight last night and this morning when I checked it, it
was
> > > still
> > > running. I then ran it again and after 20 mins or so it freezes. The
> > > amount
> > > of time it takes until it freezes is unpredictable. The funny thing
is
> > > when
> > > running it under VS.NET debug mode, after the app freezes, the serial
> > > processing is still taking place, it's the networking stuff that's
stopped
> > > (i.e. the client no longer receives the 1500 bytes every ten secs).
Would
> > > the
> > > number of threads running cause this freezing to take place? I
honestly
> > > don't
> > > know where to begin to fix this problem. My app NEEDS to run for long
> > > periods
> > > of time (i.e. over 12 hours). Can anyone shed any light on what might
be
> > > causing this or where I should start looking? Thanks in advance.
> > >
> > > Kind Regards,
> > >
> > > Michael--J
> >
> >
> >
>

Hi,

I did more tests and have encountered a few strange behaviours. The test
only involved port1 and port3. Each port processed serial input composed of
40 packets/sec where each packet averaged around 30 bytes in size. In the
background, i still have the same 3 timers working as well as the IP stuff
(refer to my first post regarding what my app does).

Ok, when i deploy the app to my device in debug mode, it runs fine until
some arbitrary point in time where the console just freezes (Console's cursor
stops flashing and system time stops). However, after waiting a while, I
noticed that the cursor actually blinked to it’s opposite colour and the time
updated itself to the current time and then it “freezes” again. I don’t think
the app is actually “frozen”, it’s still running (in the background somehow)
but the IP networking stuff isn’t active. Then i decided to remove port1's
serial input and after some time, the app began to work properly again (i.e.
Console's cursor was flashing and the system time was working). I reconnect
port1's input, the app "freezes" again after a while. I remove port1's input,
and it works again, and so on.

Does having 4 separate threads, each processing serial input, cause problems
in resource-contrained devices or is this still a race condition issue? Any
ideas as to why the behaviour i mentioned above happens? Thanks in advance.

Michael--J.

""Ilya Tumanov [MS]"" wrote:

>
> If something's corrupted, anything could happen.
> May be, you have a loop you could never leave because another thread
> messing with loop counter.
> Or, may be, you have a classical deadlock. Whatever the reason, it is
> fixable.
>
> Just carefully identify all shared objects and add locking if these objects
> are not thread safe.
>
> If you're using some sort of custom semaphores (not the lock statement),
> don't forget to unlock objects even if you have an exception.
> You might use finally blocks to do so.
>
> Best regards,
>
> Ilya
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> --------------------
> > Thread-Topic: Console app freezes
> > thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
> > X-WBNR-Posting-Host: 211.26.115.247
> > From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <(E-Mail Removed)>
> > References: <2A88D523-2302-4891-943E-(E-Mail Removed)>
> <41c11d2a$(E-Mail Removed)>
> > Subject: Re: Console app freezes
> > Date: Thu, 16 Dec 2004 03:17:08 -0800
> > Lines: 100
> > Message-ID: <BE00D6F5-A077-47D8-9C4A-(E-Mail Removed)>
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> > charset="Utf-8"
> > Content-Transfer-Encoding: 7bit
> > X-Newsreader: Microsoft CDO for Windows 2000
> > Content-Class: urn:content-classes:message
> > Importance: normal
> > Priority: normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> > Newsgroups: microsoft.public.dotnet.framework.compactframework
> > NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> > Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> > Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.compactframework:67045
> > X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
> >
> > Thanks for your quick reply. I see what you are getting at. But how would
> a
> > race condition cause a hang? I thought it usually just corrupts the
> proper
> > value of an object or variable.
> >
> > I'm getting quite worried because i have been working on this app for
> quite
> > some time now and to find out it can't last for long periods of time is
> > really disappointing. I just want to make sure whether things like this
> are
> > fixable or if it's inherent with running multithreaded apps on
> > resource-contrained devices. It's just very wierd that sometimes it runs
> for
> > hours (it ran for 10 hours once) and at other times it freezes after 20,
> or
> > 30 mins or so. I'll have a look and see if i can find any race
> conditions.
> > Thanks in advance.
> >
> > Michael--J.
> >
> > "Ilya Tumanov [MS]" wrote:
> >
> > > You probably have a race condition somewhere; this is the common reason
> for
> > > multithreaded applications to hang.
> > >
> > > Make sure all shared (between threads) objects are properly
> locked/unlocked.
> > >
> > >
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Ilya
> > >
> > >
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > >
> > >
> > > "Michael--J" <(E-Mail Removed)> wrote in message
> > > news:2A88D523-2302-4891-943E-(E-Mail Removed)...
> > > > Hi,
> > > >
> > > > I've written a C# console app that does a lot of things
> simultaneously.
> > > > The
> > > > device being used is an FB6500
> > > > (http://www.fabiatech.com/products/fb6500.htm)
> > > > running Windows CE 5.0. These are all the things the app does:
> > > >
> > > > 1. Uses four threads to scan four COM ports - each port processes
> real
> > > > time
> > > > data composed of packets. These packets are on average 25 bytes long
> and
> > > > throughput is around 15 packets/sec. So all ports combined process 60
> > > > packets/sec.
> > > >
> > > > 2. Opens two network sockets - 1 for sending data and another for
> > > > receiving.
> > > > The receiving socket listens for incoming commands from a connected
> > > > client.
> > > >
> > > > 3. Uses 3 timers - one which runs every 10 seconds sends 1500 bytes
> of
> > > > data
> > > > through a socket to a connected client, another which runs every
> minute
> > > > checks the status of certain variables, and the third runs every hour
> and
> > > > uses RDA (remote data access) to synchronize a remote SQL Server 2000
> > > > database.
> > > >
> > > > 4. Keeps a log of things that may happen by keeping a file open and
> > > > writing
> > > > to it when necessary.
> > > >
> > > > I also need to run a client on a desktop PC which connects to the
> > > > listening
> > > > socket of the app on the device. This client simply receives the 1500
> > > > bytes
> > > > of data every ten seconds and updates a form. When running the app on
> the
> > > > device, it works fine functionally but I have noticed that a lot of
> times
> > > > the
> > > > console app freezes after a while (the mouse is still movable but I
> can't
> > > > press anything, the system time at the bottom right corner also
> freezes).
> > > > I
> > > > ran it overnight last night and this morning when I checked it, it
> was
> > > > still
> > > > running. I then ran it again and after 20 mins or so it freezes. The
> > > > amount
> > > > of time it takes until it freezes is unpredictable. The funny thing
> is
> > > > when
> > > > running it under VS.NET debug mode, after the app freezes, the serial
> > > > processing is still taking place, it's the networking stuff that's
> stopped
> > > > (i.e. the client no longer receives the 1500 bytes every ten secs).
> Would
> > > > the
> > > > number of threads running cause this freezing to take place? I
> honestly
> > > > don't
> > > > know where to begin to fix this problem. My app NEEDS to run for long
> > > > periods
> > > > of time (i.e. over 12 hours). Can anyone shed any light on what might
> be
> > > > causing this or where I should start looking? Thanks in advance.
> > > >
> > > > Kind Regards,
> > > >
> > > > Michael--J
> > >
> > >
> > >
> >
>
>

This behavior seem to be a result if excessive CPU load.
Do you have some tight loops anywhere? Say, waiting for something?
Do you know what your app will do in case more data is coming from serial
port(s) than can be processed?
Could it wait for available buffer in a loop without sleep() in it?
That would cause the "serial" thread to use 100% CPU, which would slow down
all other thread, which would slow down data processing, which would cause
"serial" thread to wait... and so on. As you remove incoming data, your app
would eventually process data and unlock itself.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
> Thread-Topic: Console app freezes
> thread-index: AcTmVRfikLPVHZaeRoiMCjHGM79gMA==
> X-WBNR-Posting-Host: 202.6.138.45
> From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <(E-Mail Removed)>
> References: <2A88D523-2302-4891-943E-(E-Mail Removed)>
<41c11d2a$(E-Mail Removed)>
<BE00D6F5-A077-47D8-9C4A-(E-Mail Removed)>
<(E-Mail Removed)>
> Subject: Re: Console app freezes
> Date: Sun, 19 Dec 2004 21:31:02 -0800
> Lines: 204
> Message-ID: <728DC81F-04A6-43A7-BCE5-(E-Mail Removed)>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="Utf-8"
> Content-Transfer-Encoding: 8bit
> X-Newsreader: Microsoft CDO for Windows 2000
> Content-Class: urn:content-classes:message
> Importance: normal
> Priority: normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> Newsgroups: microsoft.public.dotnet.framework.compactframework
> NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67211
> X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
>
> Hi,
>
> I did more tests and have encountered a few strange behaviours. The test
> only involved port1 and port3. Each port processed serial input composed
of
> 40 packets/sec where each packet averaged around 30 bytes in size. In the
> background, i still have the same 3 timers working as well as the IP
stuff
> (refer to my first post regarding what my app does).
>
> Ok, when i deploy the app to my device in debug mode, it runs fine until
> some arbitrary point in time where the console just freezes (Console's
cursor
> stops flashing and system time stops). However, after waiting a while, I
> noticed that the cursor actually blinked to it’s opposite colour and
the time
> updated itself to the current time and then it “freezes” again. I
don’t think
> the app is actually “frozen”, it’s still running (in the background
somehow)
> but the IP networking stuff isn’t active. Then i decided to remove
port1's
> serial input and after some time, the app began to work properly again
(i.e.
> Console's cursor was flashing and the system time was working). I
reconnect
> port1's input, the app "freezes" again after a while. I remove port1's
input,
> and it works again, and so on.
>
> Does having 4 separate threads, each processing serial input, cause
problems
> in resource-contrained devices or is this still a race condition issue?
Any
> ideas as to why the behaviour i mentioned above happens? Thanks in
advance.
>
> Michael--J.
>
> ""Ilya Tumanov [MS]"" wrote:
>
> >
> > If something's corrupted, anything could happen.
> > May be, you have a loop you could never leave because another thread
> > messing with loop counter.
> > Or, may be, you have a classical deadlock. Whatever the reason, it is
> > fixable.
> >
> > Just carefully identify all shared objects and add locking if these
objects
> > are not thread safe.
> >
> > If you're using some sort of custom semaphores (not the lock
statement),
> > don't forget to unlock objects even if you have an exception.
> > You might use finally blocks to do so.
> >
> > Best regards,
> >
> > Ilya
> >
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> > --------------------
> > > Thread-Topic: Console app freezes
> > > thread-index: AcTjYMfjNS4Xr4DlR9GS/Qlk1bulQw==
> > > X-WBNR-Posting-Host: 211.26.115.247
> > > From: "=?Utf-8?B?TWljaGFlbC0tSg==?="
<(E-Mail Removed)>
> > > References: <2A88D523-2302-4891-943E-(E-Mail Removed)>
> > <41c11d2a$(E-Mail Removed)>
> > > Subject: Re: Console app freezes
> > > Date: Thu, 16 Dec 2004 03:17:08 -0800
> > > Lines: 100
> > > Message-ID: <BE00D6F5-A077-47D8-9C4A-(E-Mail Removed)>
> > > MIME-Version: 1.0
> > > Content-Type: text/plain;
> > > charset="Utf-8"
> > > Content-Transfer-Encoding: 7bit
> > > X-Newsreader: Microsoft CDO for Windows 2000
> > > Content-Class: urn:content-classes:message
> > > Importance: normal
> > > Priority: normal
> > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> > > Newsgroups: microsoft.public.dotnet.framework.compactframework
> > > NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> > > Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> > > Xref: cpmsftngxa10.phx.gbl
> > microsoft.public.dotnet.framework.compactframework:67045
> > > X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
> > >
> > > Thanks for your quick reply. I see what you are getting at. But how
would
> > a
> > > race condition cause a hang? I thought it usually just corrupts the
> > proper
> > > value of an object or variable.
> > >
> > > I'm getting quite worried because i have been working on this app for
> > quite
> > > some time now and to find out it can't last for long periods of time
is
> > > really disappointing. I just want to make sure whether things like
this
> > are
> > > fixable or if it's inherent with running multithreaded apps on
> > > resource-contrained devices. It's just very wierd that sometimes it
runs
> > for
> > > hours (it ran for 10 hours once) and at other times it freezes after
20,
> > or
> > > 30 mins or so. I'll have a look and see if i can find any race
> > conditions.
> > > Thanks in advance.
> > >
> > > Michael--J.
> > >
> > > "Ilya Tumanov [MS]" wrote:
> > >
> > > > You probably have a race condition somewhere; this is the common
reason
> > for
> > > > multithreaded applications to hang.
> > > >
> > > > Make sure all shared (between threads) objects are properly
> > locked/unlocked.
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > >
> > > >
> > > > Ilya
> > > >
> > > >
> > > >
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > >
> > > >
> > > > "Michael--J" <(E-Mail Removed)> wrote in message
> > > > news:2A88D523-2302-4891-943E-(E-Mail Removed)...
> > > > > Hi,
> > > > >
> > > > > I've written a C# console app that does a lot of things
> > simultaneously.
> > > > > The
> > > > > device being used is an FB6500
> > > > > (http://www.fabiatech.com/products/fb6500.htm)
> > > > > running Windows CE 5.0. These are all the things the app does:
> > > > >
> > > > > 1. Uses four threads to scan four COM ports - each port processes
> > real
> > > > > time
> > > > > data composed of packets. These packets are on average 25 bytes
long
> > and
> > > > > throughput is around 15 packets/sec. So all ports combined
process 60
> > > > > packets/sec.
> > > > >
> > > > > 2. Opens two network sockets - 1 for sending data and another for
> > > > > receiving.
> > > > > The receiving socket listens for incoming commands from a
connected
> > > > > client.
> > > > >
> > > > > 3. Uses 3 timers - one which runs every 10 seconds sends 1500
bytes
> > of
> > > > > data
> > > > > through a socket to a connected client, another which runs every
> > minute
> > > > > checks the status of certain variables, and the third runs every
hour
> > and
> > > > > uses RDA (remote data access) to synchronize a remote SQL Server
2000
> > > > > database.
> > > > >
> > > > > 4. Keeps a log of things that may happen by keeping a file open
and
> > > > > writing
> > > > > to it when necessary.
> > > > >
> > > > > I also need to run a client on a desktop PC which connects to the
> > > > > listening
> > > > > socket of the app on the device. This client simply receives the
1500
> > > > > bytes
> > > > > of data every ten seconds and updates a form. When running the
app on
> > the
> > > > > device, it works fine functionally but I have noticed that a lot
of
> > times
> > > > > the
> > > > > console app freezes after a while (the mouse is still movable but
I
> > can't
> > > > > press anything, the system time at the bottom right corner also
> > freezes).
> > > > > I
> > > > > ran it overnight last night and this morning when I checked it,
it
> > was
> > > > > still
> > > > > running. I then ran it again and after 20 mins or so it freezes.
The
> > > > > amount
> > > > > of time it takes until it freezes is unpredictable. The funny
thing
> > is
> > > > > when
> > > > > running it under VS.NET debug mode, after the app freezes, the
serial
> > > > > processing is still taking place, it's the networking stuff
that's
> > stopped
> > > > > (i.e. the client no longer receives the 1500 bytes every ten
secs).
> > Would
> > > > > the
> > > > > number of threads running cause this freezing to take place? I
> > honestly
> > > > > don't
> > > > > know where to begin to fix this problem. My app NEEDS to run for
long
> > > > > periods
> > > > > of time (i.e. over 12 hours). Can anyone shed any light on what
might
> > be
> > > > > causing this or where I should start looking? Thanks in advance.
> > > > >
> > > > > Kind Regards,
> > > > >
> > > > > Michael--J
> > > >
> > > >
> > > >
> > >
> >
> >
>

I've found in my .NET TCP/IP projects (on Pocket PC) that the sockets
can starve very easily if there is a lack of system idle time. I
actually had to put in Application.DoEvents into my communication code.
I can only assume the TCP/IP classes use hidden windows for internal
messaging and the message pump was getting backlogged. Use great
caution with the DoEvents, you don't want to over do it.

HTH,
Tom C.

My app uses OpenNETCF.org’s serial comms code with a few modifications in
their Port.cs class. This class simply sets up a thread called
‘CommEventThread’ that continually loops the associated com port for data.
However, I had to modify this to reflect the modifications I made to the
lower level serial drivers. The serial drivers were changed such that it
suited the data it was processing. The data was basically composed of packets
separated by parity errors. I couldn’t use a parity error event to
distinguish between packets because the app couldn’t keep up with the number
of parity error events being raised. Instead, I modified the serial driver
such that it places an escape ‘f0’ character in the receive stream whenever
it detected a parity error and my app simply needed to locate this ‘f0’
character. To distinguish between an escape ‘f0’ character between an actual
data ‘f0’, I replaced the data one with a 6-byte signature which my higher
level app also searches for. So in pseudo code, this is how the
CommEventThread in Port.cs looks like:

private void CommEventThread()
{
while(hPort != invalidHandle)
{

// Wait for a comm event to take place;
WaitForCommEvent();

if(error event)
{
// Handle error;
}

if(data received)
{
do
{
ReadFile() to rxFIFO buffer;
}while(bytesread > 0)
}

while(rxFIFO.Count > 0)
{
byte u = rxFIFO.Dequeue();

if(u == any byte)
{
// Add ‘u’ to progressBuffer ArrayList
progressBuffer.Add(u);
}

if(u == ‘f0’)
{
// Raise ParityError() event and clear progressBuffer;
ParityError();
progressBuffer = new ArrayList();
}

if(u is part of 6-byte signature)
{
// Take note of it;
}

if(u is last byte of 6-byte signature)
{
// Insert ‘f0’ in the data;
progressBuffer.Add(u);
}
}
}
}

I also added the method ReadProgressBuffer() in Port.cs which gets the
current progressBuffer contents when a parity error event is raised. This
will be called by my main app.

public byte[] ReadProgressBuffer(){
return (byte[])progressBuffer.ToArray(typeof(byte));
}

In my main code, I instantiate 4 port objects which means that I introduce 4
CommEventThreads executing the above code in non-stop looping. My main also
handles the ParityError events raised by each port by creating 4 indentical
event handlers that process the data by firstly calling
portX.ReadProgressBuffer(). Below is the pseudo code:

private void portX_ParityError()
{
byte[] packet = portX.ReadProgressBuffer();

// Process the byte array here;
// This predominantly involves packet validation -
// CRC checks, and updating a set of global data;
}

When this handler returns, the CommEventThread continues by clearing the
progressBuffer and repeating the whole process.

In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
described in my first post). Would it definitely be a CPU overload issue? If
you need more information regarding my app or any of its code, please feel
free to ask. Thanks again.


""Ilya Tumanov [MS]"" wrote:

> This behavior seem to be a result if excessive CPU load.
> Do you have some tight loops anywhere? Say, waiting for something?
> Do you know what your app will do in case more data is coming from serial
> port(s) than can be processed?
> Could it wait for available buffer in a loop without sleep() in it?
> That would cause the "serial" thread to use 100% CPU, which would slow down
> all other thread, which would slow down data processing, which would cause
> "serial" thread to wait... and so on. As you remove incoming data, your app
> would eventually process data and unlock itself.
>
> Best regards,
>
> Ilya
>

Would it matter if my app was only a console app. Isn't the Application class
found within the System.Windows.Forms namespace? Thanks.

"(E-Mail Removed)" wrote:

> I've found in my .NET TCP/IP projects (on Pocket PC) that the sockets
> can starve very easily if there is a lack of system idle time. I
> actually had to put in Application.DoEvents into my communication code.
> I can only assume the TCP/IP classes use hidden windows for internal
> messaging and the message pump was getting backlogged. Use great
> caution with the DoEvents, you don't want to over do it.
>
> HTH,
> Tom C.
>
>

What's in WaitForCommEvent()? It's not a while loop which checks for some
variable set from event, is it?

I would also suggest using circular buffer instead of creating new array
lists and arrays for every packet.
You'll need to firure out what to do in case buffer overflows (terminate,
log event, ignore extra data, etc.).

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
> Thread-Topic: Console app freezes
> thread-index: AcTm7jZvbF/weKNQT22YrExp4stGvg==
> X-WBNR-Posting-Host: 202.6.138.45
> From: "=?Utf-8?B?TWljaGFlbC0tSg==?=" <(E-Mail Removed)>
> References: <2A88D523-2302-4891-943E-(E-Mail Removed)>
<41c11d2a$(E-Mail Removed)>
<BE00D6F5-A077-47D8-9C4A-(E-Mail Removed)>
<(E-Mail Removed)>
<728DC81F-04A6-43A7-BCE5-(E-Mail Removed)>
<UQI8R$(E-Mail Removed)>
> Subject: Re: Console app freezes
> Date: Mon, 20 Dec 2004 15:47:06 -0800
> Lines: 116
> Message-ID: <17826F3A-DA24-4C76-A645-(E-Mail Removed)>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="Utf-8"
> Content-Transfer-Encoding: 8bit
> X-Newsreader: Microsoft CDO for Windows 2000
> Content-Class: urn:content-classes:message
> Importance: normal
> Priority: normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> Newsgroups: microsoft.public.dotnet.framework.compactframework
> NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.compactframework:67289
> X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework
>
> My app uses OpenNETCF.org’s serial comms code with a few modifications
in
> their Port.cs class. This class simply sets up a thread called
> ‘CommEventThread’ that continually loops the associated com port for
data.
> However, I had to modify this to reflect the modifications I made to the
> lower level serial drivers. The serial drivers were changed such that it
> suited the data it was processing. The data was basically composed of
packets
> separated by parity errors. I couldn’t use a parity error event to
> distinguish between packets because the app couldn’t keep up with the
number
> of parity error events being raised. Instead, I modified the serial
driver
> such that it places an escape ‘f0’ character in the receive stream
whenever
> it detected a parity error and my app simply needed to locate this ‘
f0’
> character. To distinguish between an escape ‘f0’ character between an
actual
> data ‘f0’, I replaced the data one with a 6-byte signature which my
higher
> level app also searches for. So in pseudo code, this is how the
> CommEventThread in Port.cs looks like:
>
> private void CommEventThread()
> {
> while(hPort != invalidHandle)
> {
>
> // Wait for a comm event to take place;
> WaitForCommEvent();
>
> if(error event)
> {
> // Handle error;
> }
>
> if(data received)
> {
> do
> {
> ReadFile() to rxFIFO buffer;
> }while(bytesread > 0)
> }
>
> while(rxFIFO.Count > 0)
> {
> byte u = rxFIFO.Dequeue();
>
> if(u == any byte)
> {
> // Add ‘u’ to progressBuffer ArrayList
> progressBuffer.Add(u);
> }
>
> if(u == ‘f0’)
> {
> // Raise ParityError() event and clear progressBuffer;
> ParityError();
> progressBuffer = new ArrayList();
> }
>
> if(u is part of 6-byte signature)
> {
> // Take note of it;
> }
>
> if(u is last byte of 6-byte signature)
> {
> // Insert ‘f0’ in the data;
> progressBuffer.Add(u);
> }
> }
> }
> }
>
> I also added the method ReadProgressBuffer() in Port.cs which gets the
> current progressBuffer contents when a parity error event is raised. This
> will be called by my main app.
>
> public byte[] ReadProgressBuffer(){
> return (byte[])progressBuffer.ToArray(typeof(byte));
> }
>
> In my main code, I instantiate 4 port objects which means that I
introduce 4
> CommEventThreads executing the above code in non-stop looping. My main
also
> handles the ParityError events raised by each port by creating 4
indentical
> event handlers that process the data by firstly calling
> portX.ReadProgressBuffer(). Below is the pseudo code:
>
> private void portX_ParityError()
> {
> byte[] packet = portX.ReadProgressBuffer();
>
> // Process the byte array here;
> // This predominantly involves packet validation -
> // CRC checks, and updating a set of global data;
> }
>
> When this handler returns, the CommEventThread continues by clearing the
> progressBuffer and repeating the whole process.
>
> In addition to this, I have 3 timers, TCP/IP stuff, and log keeping (as
> described in my first post). Would it definitely be a CPU overload issue?
If
> you need more information regarding my app or any of its code, please
feel
> free to ask. Thanks again.
>
>
> ""Ilya Tumanov [MS]"" wrote:
>
> > This behavior seem to be a result if excessive CPU load.
> > Do you have some tight loops anywhere? Say, waiting for something?
> > Do you know what your app will do in case more data is coming from
serial
> > port(s) than can be processed?
> > Could it wait for available buffer in a loop without sleep() in it?
> > That would cause the "serial" thread to use 100% CPU, which would slow
down
> > all other thread, which would slow down data processing, which would
cause
> > "serial" thread to wait... and so on. As you remove incoming data, your
app
> > would eventually process data and unlock itself.
> >
> > Best regards,
> >
> > Ilya
> >
>