By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,582 Members | 1,720 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,582 IT Pros & Developers. It's quick & easy.

multi threading

P: n/a
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..
Nov 20 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
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****@streamyx.com> wrote in message
news:O0**************@tk2msftngp13.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..

Nov 20 '05 #2

P: n/a
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.
Nov 20 '05 #3

P: n/a
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.BeginInvoke.

--
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.
Nov 20 '05 #4

P: n/a

"CJ Taylor" <no****@blowgoats.com> wrote in message
news:Ob**************@TK2MSFTNGP09.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****@streamyx.com> wrote in message
news:O0**************@tk2msftngp13.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..


Nov 20 '05 #5

P: n/a

"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@tk2msftngp13.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.

Nov 20 '05 #6

P: n/a
hi,

"Dick Grier" <di**************@msn.com> wrote in message
news:uQ**************@TK2MSFTNGP09.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.BeginInvoke.
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.

Nov 20 '05 #7

P: n/a
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.Exception, 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****@streamyx.com> wrote in message
news:Ou**************@tk2msftngp13.phx.gbl...

"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@tk2msftngp13.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.


Nov 20 '05 #8

P: n/a
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.Exception, 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****@blowgoats.com> wrote in message
news:%2****************@TK2MSFTNGP11.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.Exception, 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****@streamyx.com> wrote in message
news:Ou**************@tk2msftngp13.phx.gbl...

"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@tk2msftngp13.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.



Nov 20 '05 #9

P: n/a

"aikwee" <ai****@streamyx.com> wrote in message
news:eI**************@TK2MSFTNGP11.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.Exception, 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****@blowgoats.com> wrote in message
news:%2****************@TK2MSFTNGP11.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.Exception, 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****@streamyx.com> wrote in message
news:Ou**************@tk2msftngp13.phx.gbl...

"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@tk2msftngp13.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.
>
>



Nov 20 '05 #10

P: n/a
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.
Nov 20 '05 #11

P: n/a
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.
Nov 20 '05 #12

P: n/a
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.
Nov 20 '05 #13

P: n/a
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.
Nov 20 '05 #14

P: n/a
thanks guys, i guess i have to dig deepper to find what's going on....
"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
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.

Nov 20 '05 #15

P: n/a
HI, I found out that is the RS232 Class that have causing me problem. It
happen when i use it with

..Workingmode = overlapped

"aikwee" <ai****@spammer.com> wrote in message
news:uX**************@TK2MSFTNGP10.phx.gbl...
thanks guys, i guess i have to dig deepper to find what's going on....
"Dick Grier" <di**************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
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.



Nov 20 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.