multi threading

  • Thread starter Thread starter aikwee
  • Start date Start date
A

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..
 
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
 
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.
 
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.
 
CJ Taylor said:
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?
Click to expand...
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?)
Click to expand...

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 ?
 
Dick Grier said:
Hi,

I presume that each thread monitors a separate serial port?
Click to expand...
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.
Click to expand...

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

what will happen to unhandled error ?
 
hi,

Dick Grier said:
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.
Click to expand...

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,
Click to expand...

this look like alien language to me.... do you have a pointer to a good
reference... ?
 
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
 
thanks for repling..
On error resume next doesn't work anymore. Thats the way you use Try Catch
Finally Statements...
Click to expand...
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.
Click to expand...

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.
Click to expand...

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)
 
aikwee said:
thanks for repling..
Click to expand...

not a problem
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.


i presume what you mean by "primary thread" is the thread that start the 8
threads....
Click to expand...

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)
Click to expand...

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.
 
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.
 
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.
 
HI, I found out that is the RS232 Class that have causing me problem. It
happen when i use it with

..Workingmode = overlapped
 
Back
Top