multi threading

[aikwee]

hi all, i have a software written in vb.net which has many thread in it.

The software basically use about 8 threads to monitor in coming data
from serial port,

and some other thread that process those data.

What happen is the software will suddenly "dissapear" after running for
some time.

theres no error message or anything, it just end by itself.....

I wondering anyone got this kind of experience before ?

any clue someone ?

I am loosing my hair.... sigh..

[CJ Taylor]

Alright,

Well, this could be 1 of 1,000,000,000 issues probably. A little vague, but
thats ok. =)

A few questions, especially when your talking about using 8 threads on a
serial port...

1) Why are you using 8 threads to monitor a serial port? You should only
need 1 (depending on what your doing, I really don't see a reason for more,
in fact, I could see problems with this... Especially depending on what your
doing with this data coming from the port. What kind of syncronization are
you using? SyncLock? Muting? Roll your own?

Explain a little more what your doing, and I'll do my best to help you out.
As I've learned from countless people in here, when your using
multi-threading, make sure you have a reason. =)

I think the overall answer you'll be looking for is, 1 thread to monitor and
many to process long functions etc. But the reason its dying *could* be an
unmanaged code issue, I don't know, I have no idea what your code is nor how
your accessing the serial port (API I presume?)

Let me know.

CJ
"aikwee" <ai****@streamy x.com> wrote in message
news:O0******** ******@tk2msftn gp13.phx.gbl...

hi all, i have a software written in vb.net which has many thread in it.

The software basically use about 8 threads to monitor in coming data
from serial port,

and some other thread that process those data.

What happen is the software will suddenly "dissapear" after running for
some time.

theres no error message or anything, it just end by itself.....

I wondering anyone got this kind of experience before ?

any clue someone ?

I am loosing my hair.... sigh..

[Dick Grier]

Hi,

I presume that each thread monitors a separate serial port?

If there are no errors (are you sure you aren't discarding a possible error
by a higher-level error trap), then it will be very hard to find. Offhand,
I don't have any suggestion. These things require hands-on debugging --
we'd just be guessing without having code to examine.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[Dick Grier]

However... If you are sending data from the threads into an STAThread
process (such as the UI), then you need to marshal the data properly,
otherwise you will experience random failures. You do this by using
Control.Invoke or Control.BeginIn voke.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[aikwee]

"CJ Taylor" <no****@blowgoa ts.com> wrote in message
news:Ob******** ******@TK2MSFTN GP09.phx.gbl...

Alright,

Well, this could be 1 of 1,000,000,000 issues probably. A little vague, but thats ok. =)

A few questions, especially when your talking about using 8 threads on a
serial port...

1) Why are you using 8 threads to monitor a serial port? You should only
need 1 (depending on what your doing, I really don't see a reason for more, in fact, I could see problems with this... Especially depending on what your doing with this data coming from the port. What kind of syncronization are you using? SyncLock? Muting? Roll your own?
the fact is i am monitoring 8 serial ports.
Explain a little more what your doing, and I'll do my best to help you out. As I've learned from countless people in here, when your using
multi-threading, make sure you have a reason. =)

I think the overall answer you'll be looking for is, 1 thread to monitor and many to process long functions etc. But the reason its dying *could* be an unmanaged code issue, I don't know, I have no idea what your code is nor how your accessing the serial port (API I presume?)
i am using the vb.net example for acessing serial port as a model for my
program,...
i see a lot of api calls, is it the root of the problem ?
Let me know.

CJ
"aikwee" <ai****@streamy x.com> wrote in message
news:O0******** ******@tk2msftn gp13.phx.gbl...

hi all, i have a software written in vb.net which has many thread in it.

The software basically use about 8 threads to monitor in coming data
from serial port,

and some other thread that process those data.

What happen is the software will suddenly "dissapear" after running for some time.

theres no error message or anything, it just end by itself.....

I wondering anyone got this kind of experience before ?

any clue someone ?

I am loosing my hair.... sigh..

[aikwee]

"Dick Grier" <di************ **@msn.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

Hi,

I presume that each thread monitors a separate serial port?
absolutely right....
If there are no errors (are you sure you aren't discarding a possible error by a higher-level error trap), then it will be very hard to find. Offhand, I don't have any suggestion. These things require hands-on debugging --
we'd just be guessing without having code to examine.
oops, i didn't handle all error properly... i presume
try .. catch.. end try = on error resume next

what will happen to unhandled error ?

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[aikwee]

hi,

"Dick Grier" <di************ **@msn.com> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...

However... If you are sending data from the threads into an STAThread
process (such as the UI), then you need to marshal the data properly,
otherwise you will experience random failures. You do this by using
Control.Invoke or Control.BeginIn voke.
oh... i did update some UI but for debugging purposes, my porgram suppose to
run headless...
If you are sending data from the threads into an STAThread
process (such as the UI), then you need to marshal the data properly,
this look like alien language to me.... do you have a pointer to a good
reference... ?

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[CJ Taylor]

On error resume next doesn't work anymore. Thats the way you use Try Catch
Finally Statements...

Unhandled errors depends on how you catch...

if you catch System.Exceptio n, you'll catch *everything* that could go wrong
(good approach for testing). and then recover.

As far as monitoring 8 different serial ports, are you writing data back to
"primary" thread? Thats why I was asking about your syncronization.

-CJ

-CJ
"aikwee" <ai****@streamy x.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

"Dick Grier" <di************ **@msn.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

Hi,

I presume that each thread monitors a separate serial port?

absolutely right....

If there are no errors (are you sure you aren't discarding a possible

error

by a higher-level error trap), then it will be very hard to find.

Offhand,

I don't have any suggestion. These things require hands-on debugging --
we'd just be guessing without having code to examine.

oops, i didn't handle all error properly... i presume
try .. catch.. end try = on error resume next

what will happen to unhandled error ?

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[aikwee]

thanks for repling..

On error resume next doesn't work anymore. Thats the way you use Try Catch Finally Statements... Unhandled errors depends on how you catch...

if you catch System.Exceptio n, you'll catch *everything* that could go wrong (good approach for testing). and then recover.
i do :
Try
....some codes here
catch ex as exception
`doesn't do anything here
end try

in a thread so that it will recover and run on and on again....
is it right ?
As far as monitoring 8 different serial ports, are you writing data back to "primary" thread? Thats why I was asking about your syncronization.
i presume what you mean by "primary thread" is the thread that start the 8
threads....

no , 8 serial ports threads don't write back to main thread, the just put
the data in a class
for other processes to read (only)
"CJ Taylor" <no****@blowgoa ts.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. On error resume next doesn't work anymore. Thats the way you use Try Catch Finally Statements...

Unhandled errors depends on how you catch...

if you catch System.Exceptio n, you'll catch *everything* that could go wrong (good approach for testing). and then recover.

As far as monitoring 8 different serial ports, are you writing data back to "primary" thread? Thats why I was asking about your syncronization.

-CJ

-CJ
"aikwee" <ai****@streamy x.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

"Dick Grier" <di************ **@msn.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

Hi,

I presume that each thread monitors a separate serial port?

absolutely right....

If there are no errors (are you sure you aren't discarding a possible

error

by a higher-level error trap), then it will be very hard to find.

Offhand,

I don't have any suggestion. These things require hands-on debugging -- we'd just be guessing without having code to examine.

oops, i didn't handle all error properly... i presume
try .. catch.. end try = on error resume next

what will happen to unhandled error ?

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

[CJ Taylor]

"aikwee" <ai****@streamy x.com> wrote in message
news:eI******** ******@TK2MSFTN GP11.phx.gbl...

thanks for repling..
not a problem

On error resume next doesn't work anymore. Thats the way you use Try

Catch

Finally Statements...

Unhandled errors depends on how you catch...

if you catch System.Exceptio n, you'll catch *everything* that could go

wrong

(good approach for testing). and then recover.

i do :
Try
...some codes here
catch ex as exception
`doesn't do anything here
end try

in a thread so that it will recover and run on and on again....
is it right ?

Right.

As far as monitoring 8 different serial ports, are you writing data back

to

"primary" thread? Thats why I was asking about your syncronization.

i presume what you mean by "primary thread" is the thread that start the

8 threads....

Yeah. exactly.
no , 8 serial ports threads don't write back to main thread, the just put
the data in a class
for other processes to read (only)
Thats where you might want to use some SyncLocking of some kind. Deny
another thread the rights to read or write from here becaues you could have
some data issues.. Maybe, maybe not, I'm just anal that way and like to
have it that way. You still have communication between 2 threads through
this class (whether it goes directly back to the primary thread or not) in
which case you can still get some errors or inaccurate data.
"CJ Taylor" <no****@blowgoa ts.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

On error resume next doesn't work anymore. Thats the way you use Try

Catch

Finally Statements...

Unhandled errors depends on how you catch...

if you catch System.Exceptio n, you'll catch *everything* that could go

wrong

(good approach for testing). and then recover.

As far as monitoring 8 different serial ports, are you writing data back

to

"primary" thread? Thats why I was asking about your syncronization.

-CJ

-CJ
"aikwee" <ai****@streamy x.com> wrote in message
news:Ou******** ******@tk2msftn gp13.phx.gbl...

"Dick Grier" <di************ **@msn.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
> Hi,
>
> I presume that each thread monitors a separate serial port?
>
absolutely right....

> If there are no errors (are you sure you aren't discarding a possible error
> by a higher-level error trap), then it will be very hard to find.
Offhand,
> I don't have any suggestion. These things require hands-on debugging -- > we'd just be guessing without having code to examine.

oops, i didn't handle all error properly... i presume
try .. catch.. end try = on error resume next

what will happen to unhandled error ?

>
> --
> Richard Grier (Microsoft Visual Basic MVP)
>
> See www.hardandsoftware.net for contact information.
>
> Author of Visual Basic Programmer's Guide to Serial Communications, 3rd > Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
>
>