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]

Re: multi threading

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" <aikwee@streamy x.com> wrote in message
news:O0aAv2rfDH A.3528@tk2msftn gp13.phx.gbl...[color=blue]
> 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..
>
>[/color]

[Dick Grier]

Re: multi threading

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]

Re: multi threading

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]

Re: multi threading


"CJ Taylor" <nospam@blowgoa ts.com> wrote in message
news:ObNl$BsfDH A.1200@TK2MSFTN GP09.phx.gbl...[color=blue]
> Alright,
>
> Well, this could be 1 of 1,000,000,000 issues probably. A little vague,[/color]
but[color=blue]
> 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[/color]
more,[color=blue]
> in fact, I could see problems with this... Especially depending on what[/color]
your[color=blue]
> doing with this data coming from the port. What kind of syncronization[/color]
are[color=blue]
> you using? SyncLock? Muting? Roll your own?
>[/color]
the fact is i am monitoring 8 serial ports.
[color=blue]
> Explain a little more what your doing, and I'll do my best to help you[/color]
out.[color=blue]
> 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[/color]
and[color=blue]
> many to process long functions etc. But the reason its dying *could* be[/color]
an[color=blue]
> unmanaged code issue, I don't know, I have no idea what your code is nor[/color]
how[color=blue]
> your accessing the serial port (API I presume?)[/color]

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 ?[color=blue]
>
> Let me know.
>
> CJ
>
>
> "aikwee" <aikwee@streamy x.com> wrote in message
> news:O0aAv2rfDH A.3528@tk2msftn gp13.phx.gbl...[color=green]
> > 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[/color][/color]
for[color=blue][color=green]
> > 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..
> >
> >[/color]
>
>[/color]

[aikwee]

Re: multi threading


"Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
news:%23ehrZRsf DHA.3896@tk2msf tngp13.phx.gbl. ..[color=blue]
> Hi,
>
> I presume that each thread monitors a separate serial port?
>[/color]
absolutely right....
[color=blue]
> If there are no errors (are you sure you aren't discarding a possible[/color]
error[color=blue]
> by a higher-level error trap), then it will be very hard to find.[/color]
Offhand,[color=blue]
> I don't have any suggestion. These things require hands-on debugging --
> we'd just be guessing without having code to examine.[/color]

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

what will happen to unhandled error ?
[color=blue]
>
> --
> 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.
>
>[/color]

[aikwee]

Re: multi threading

hi,

"Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
news:uQgrxSsfDH A.2408@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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.[/color]

oh... i did update some UI but for debugging purposes, my porgram suppose to
run headless...
[color=blue]
>If you are sending data from the threads into an STAThread
> process (such as the UI), then you need to marshal the data properly,[/color]

this look like alien language to me.... do you have a pointer to a good
reference... ?
[color=blue]
>
> --
> 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.
>
>[/color]

[CJ Taylor]

Re: multi threading

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" <aikwee@streamy x.com> wrote in message
news:OutvqdtfDH A.3896@tk2msftn gp13.phx.gbl...[color=blue]
>
> "Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
> news:%23ehrZRsf DHA.3896@tk2msf tngp13.phx.gbl. ..[color=green]
> > Hi,
> >
> > I presume that each thread monitors a separate serial port?
> >[/color]
> absolutely right....
>[color=green]
> > If there are no errors (are you sure you aren't discarding a possible[/color]
> error[color=green]
> > by a higher-level error trap), then it will be very hard to find.[/color]
> Offhand,[color=green]
> > I don't have any suggestion. These things require hands-on debugging --
> > we'd just be guessing without having code to examine.[/color]
>
> oops, i didn't handle all error properly... i presume
> try .. catch.. end try = on error resume next
>
> what will happen to unhandled error ?
>[color=green]
> >
> > --
> > 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.
> >
> >[/color]
>
>[/color]

[aikwee]

Re: multi threading

thanks for repling..[color=blue]
> On error resume next doesn't work anymore. Thats the way you use Try[/color]
Catch[color=blue]
> Finally Statements...[/color]
[color=blue]
> Unhandled errors depends on how you catch...
>
> if you catch System.Exceptio n, you'll catch *everything* that could go[/color]
wrong[color=blue]
> (good approach for testing). and then recover.[/color]

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 ?
[color=blue]
> As far as monitoring 8 different serial ports, are you writing data back[/color]
to[color=blue]
> "primary" thread? Thats why I was asking about your syncronization.[/color]

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" <nospam@blowgoa ts.com> wrote in message
news:%23Bj5hhtf DHA.3700@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> On error resume next doesn't work anymore. Thats the way you use Try[/color]
Catch[color=blue]
> Finally Statements...
>
> Unhandled errors depends on how you catch...
>
> if you catch System.Exceptio n, you'll catch *everything* that could go[/color]
wrong[color=blue]
> (good approach for testing). and then recover.
>
> As far as monitoring 8 different serial ports, are you writing data back[/color]
to[color=blue]
> "primary" thread? Thats why I was asking about your syncronization.
>
> -CJ
>
> -CJ
> "aikwee" <aikwee@streamy x.com> wrote in message
> news:OutvqdtfDH A.3896@tk2msftn gp13.phx.gbl...[color=green]
> >
> > "Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
> > news:%23ehrZRsf DHA.3896@tk2msf tngp13.phx.gbl. ..[color=darkred]
> > > Hi,
> > >
> > > I presume that each thread monitors a separate serial port?
> > >[/color]
> > absolutely right....
> >[color=darkred]
> > > If there are no errors (are you sure you aren't discarding a possible[/color]
> > error[color=darkred]
> > > by a higher-level error trap), then it will be very hard to find.[/color]
> > Offhand,[color=darkred]
> > > I don't have any suggestion. These things require hands-on[/color][/color][/color]
debugging --[color=blue][color=green][color=darkred]
> > > we'd just be guessing without having code to examine.[/color]
> >
> > oops, i didn't handle all error properly... i presume
> > try .. catch.. end try = on error resume next
> >
> > what will happen to unhandled error ?
> >[color=darkred]
> > >
> > > --
> > > Richard Grier (Microsoft Visual Basic MVP)
> > >
> > > See www.hardandsoftware.net for contact information.
> > >
> > > Author of Visual Basic Programmer's Guide to Serial Communications,[/color][/color][/color]
3rd[color=blue][color=green][color=darkred]
> > > Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[CJ Taylor]

Re: multi threading


"aikwee" <aikwee@streamy x.com> wrote in message
news:eIb39ptfDH A.1712@TK2MSFTN GP11.phx.gbl...[color=blue]
> thanks for repling..[/color]

not a problem
[color=blue][color=green]
> > On error resume next doesn't work anymore. Thats the way you use Try[/color]
> Catch[color=green]
> > Finally Statements...[/color]
>[color=green]
> > Unhandled errors depends on how you catch...
> >
> > if you catch System.Exceptio n, you'll catch *everything* that could go[/color]
> wrong[color=green]
> > (good approach for testing). and then recover.[/color]
>
> 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 ?
>[/color]

Right.
[color=blue][color=green]
> > As far as monitoring 8 different serial ports, are you writing data back[/color]
> to[color=green]
> > "primary" thread? Thats why I was asking about your syncronization.[/color]
>
> i presume what you mean by "primary thread" is the thread that start the[/color]
8[color=blue]
> threads....
>[/color]

Yeah. exactly.
[color=blue]
> 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)[/color]

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.
[color=blue]
> "CJ Taylor" <nospam@blowgoa ts.com> wrote in message
> news:%23Bj5hhtf DHA.3700@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > On error resume next doesn't work anymore. Thats the way you use Try[/color]
> Catch[color=green]
> > Finally Statements...
> >
> > Unhandled errors depends on how you catch...
> >
> > if you catch System.Exceptio n, you'll catch *everything* that could go[/color]
> wrong[color=green]
> > (good approach for testing). and then recover.
> >
> > As far as monitoring 8 different serial ports, are you writing data back[/color]
> to[color=green]
> > "primary" thread? Thats why I was asking about your syncronization.
> >
> > -CJ
> >
> > -CJ
> > "aikwee" <aikwee@streamy x.com> wrote in message
> > news:OutvqdtfDH A.3896@tk2msftn gp13.phx.gbl...[color=darkred]
> > >
> > > "Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
> > > news:%23ehrZRsf DHA.3896@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[/color][/color][/color]
possible[color=blue][color=green][color=darkred]
> > > 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[/color][/color]
> debugging --[color=green][color=darkred]
> > > > 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,[/color][/color]
> 3rd[color=green][color=darkred]
> > > > Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Dick Grier]

Re: multi threading

Hi,

On Error Resume Next STILL works. Check it out. As always, it skips all
errors in scope. This is equivalent to a Try/Catch/End Try block that has
no code to trap an exception in the Catch section.

The problem is that either of these may skip an valuable exception. And, of
course, you can write Catch code that doesn't trap the exception of
interest, thus causing a logical failure that remains unexplained.

--
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]

Re: multi threading

Hi,

The UI is STAThread (Single Apartment Threaded). The Microsoft references
for Threading describe what you need to do to write from a free thread to an
STAThread code module. The example code that they show involves updating a
ListView control, I think. However, the requirements are the same
regardless, when your threaded code calls code in an STAThread (UI).

--
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]

Re: multi threading

Hi,

On Error Resume Next STILL works. Check it out. As always, it skips all
errors in scope. This is equivalent to a Try/Catch/End Try block that has
no code to trap an exception in the Catch section.

The problem is that either of these may skip an valuable exception. And, of
course, you can write Catch code that doesn't trap the exception of
interest, thus causing a logical failure that remains unexplained.

--
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]

Re: multi threading

Hi,

The UI is STAThread (Single Apartment Threaded). The Microsoft references
for Threading describe what you need to do to write from a free thread to an
STAThread code module. The example code that they show involves updating a
ListView control, I think. However, the requirements are the same
regardless, when your threaded code calls code in an STAThread (UI).

--
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]

Re: multi threading

thanks guys, i guess i have to dig deepper to find what's going on....
"Dick Grier" <dick_grierNOSP AM@msn.com> wrote in message
news:%23kXBu66f DHA.3324@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> Hi,
>
> The UI is STAThread (Single Apartment Threaded). The Microsoft references
> for Threading describe what you need to do to write from a free thread to[/color]
an[color=blue]
> STAThread code module. The example code that they show involves updating[/color]
a[color=blue]
> ListView control, I think. However, the requirements are the same
> regardless, when your threaded code calls code in an STAThread (UI).
>
> --
> 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.
>
>[/color]