About BeginInvoke/ThreadPool/Threading

[FP]

Hi,
i'm currently developing a class to communicate with a serial device,using
the SerialPort component.
Basically,the main application will interact with this class through its
method "Call",the class itself will handle all the details of a call (AT
commands included).
My problem is that i dont want the application to hang while i'm
interacting with the modem,so i have started to learn about threading.

Many people have suggested me to use BeginInvoke/EndInvoke,which relies on
pooled threads,but i just found out in some articles that author suggests
not to use pooled threads for tasks that lasts more than few seconds,which
is not my case (it might last some minutes).
Now i wonder: does this advice apply only when my application spawns many
threads? I.e. is the thread pool shared with other processes,so i have to
worry about not blocking other processes' thread pools?

So far i'm not yet sure whether to use the BeginInvoke/EndInvoke or create
a new thread,since after all my modem is a finite state machine,and i was
thinking to events as the way to signal state transitions to the main
application.Which approach would you suggest?

Thanks in advance :)

[Jon Skeet [C# MVP]]

On Nov 13, 1:20 pm, FP <[e-mail]:

i'm currently developing a class to communicate with a serial device,using
the SerialPort component.
Basically,the main application will interact with this class through its
method "Call",the class itself will handle all the details of a call (AT
commands included).
My problem is that i dont want the application to hang while i'm
interacting with the modem,so i have started to learn about threading.

Many people have suggested me to use BeginInvoke/EndInvoke,which relies on
pooled threads

That depends which BeginInvoke/EndInvoke they're talking about.
Control.BeginInvoke/Control.EndInvoke don't use threadpool threads,
but Delegate.BeginInvoke/Delegate.EndInvoke do.

<snip>

Now i wonder: does this advice apply only when my application spawns many
threads? I.e. is the thread pool shared with other processes,so i have to
worry about not blocking other processes' thread pools?

No, there's one thread pool per process.

So far i'm not yet sure whether to use the BeginInvoke/EndInvoke or create
a new thread,since after all my modem is a finite state machine,and i was
thinking to events as the way to signal state transitions to the main
application.Which approach would you suggest?

If your task is going to last quite a while, the overhead of creating
a new thread will be insignificant. Just remember that you need to
marshal back over to the UI thread (e.g. with Control.BeginInvoke)
before updating the UI.

Jon

[John Duval]

On Nov 13, 8:20 am, FP <[e-mail]:

Hi,
i'm currently developing a class to communicate with a serial device,using
the SerialPort component.
Basically,the main application will interact with this class through its
method "Call",the class itself will handle all the details of a call (AT
commands included).
My problem is that i dont want the application to hang while i'm
interacting with the modem,so i have started to learn about threading.

Many people have suggested me to use BeginInvoke/EndInvoke,which relies on
pooled threads,but i just found out in some articles that author suggests
not to use pooled threads for tasks that lasts more than few seconds,which
is not my case (it might last some minutes).
Now i wonder: does this advice apply only when my application spawns many
threads? I.e. is the thread pool shared with other processes,so i have to
worry about not blocking other processes' thread pools?

So far i'm not yet sure whether to use the BeginInvoke/EndInvoke or create
a new thread,since after all my modem is a finite state machine,and i was
thinking to events as the way to signal state transitions to the main
application.Which approach would you suggest?

Thanks in advance :)

Hi FP,
The thread pool (and threads in general) are not shared with other
processes; a thread is owned by one process only. So you do not have
to worry about blocking other processes. Unless your process is
likely to use the thread pool for other reasons, I think it's fine to
have your operations run on the thread pool threads. If you start
having a lot of these operations running concurrently (and consuming
lots of threads for a long time), you might run out of threads in the
threadpool, but it doesn't sound like your app is likely to do this.

John

[Chris Mullins [MVP - C#]]

"FP" <[e-mail]

Many people have suggested me to use BeginInvoke/EndInvoke,which relies on
pooled threads,but i just found out in some articles that author suggests
not to use pooled threads for tasks that lasts more than few seconds,which
is not my case (it might last some minutes).

[...] Which approach would you suggest?

For I/O bound tasks, Async I/O is the answer. I'm not familiar enough with
modem communication under .Net to know if it has all the BeginSend /
BeginReceive methods, but if those are present, it would likley be the best
way to go.

If the Modem infrastructure doesn't support this, then creating your own
threads is the answer...

--
Chris Mullins

[FP]

Hi,
after some deeper investigations i found out that received data are treated
in a separate thread,so i am beginning to wonder if i might really need to
create a new thread.I will better explain my application,now.

I have created a wrapper class (called USBModem) around the SerialPort
class.
The class has a public CallRemoteModem method,which starts the call
"procedure",composed of the following steps:
1)Check if modem is connected
2)Check if the signal strength is good
3)Call the remote modem

Inside the class i have an event handler for the SerialPort.DataReceived
event. This event is fired on a separate thread (i have read somewhere that
this thread operates on the threadpool), whenever data is received on the
port.This is done by the SerialPort object.
In the DataReceived event I collect received characters in a buffer until I
have a complete message:at that time i will fire a "ResponseComplete"
event.

Each step of the call procedure is actually simply writing an AT command to
the output buffer.I was thinking to handle all of this with events,
implementing the following scheme:

1-CheckModemConnection (actually a method which actually writes only "AT"
to the output buffer)

2-Wait for the received message to be complete

3-When received message is complete and correct, Check the signal (actually
writing another string to the output buffer)

4-Fire a "Step2Began" to inform main app of the state transition

5-Wait for the received message to be complete

6-When received message is complete and correct Call the remote modem (of
course,writing another string to the output buffer)

7-Fire a "CallBegan" to inform main app of the state transition

8-Wait for the received message to be complete (this step can be very long)

9-Analyze the result of the call
What suggested me to create a new thread is the fact that step8 can last
some minutes,but now,knowing that DataReceived is on another thread is
making me wonder....
Will the main app hang while i'm receiving the string from the remote
modem?
Obviously i will have to test (but i can't right now),but the fact that
DataReceived is already running on a separate thread is kinda confusing
me....

[Peter Duniho]

On 2007-11-13 12:11:18 -0800, FP <[e-mail]:

Hi,
after some deeper investigations i found out that received data are treated
in a separate thread,so i am beginning to wonder if i might really need to
create a new thread.I will better explain my application,now.

I think that for sure, you do not need to create a new thread. But
that's not to say that you can also just spend a long time reading data
from the SerialPort.

[...]
What suggested me to create a new thread is the fact that step8 can last
some minutes,but now,knowing that DataReceived is on another thread is
making me wonder....
Will the main app hang while i'm receiving the string from the remote
modem?

Not immediately, no. But depending on what thread pool is actually
being used for raising the DataReceived event, you could cause some
problems if you tie up a thread from the pool for a lengthy period of
time.

In most cases, the likelihood of a problem is low, but it does exist.

Obviously i will have to test (but i can't right now),but the fact that
DataReceived is already running on a separate thread is kinda confusing
me....

IMHO, you have a couple of options:

* Use the DataReceived event
* Use the SerialPort.BaseStream and use the async methods of that
stream (this is basically what Chris Mullins is suggesting)

I would ordinarily agree with Chris and suggest using the BaseStream.
This would involve calling Stream.BeginRead, and then in your callback
processing the data that's been read (retrieved by calling
Stream.EndRead) and calling Stream.BeginRead again.

The thing that gives me pause is that in the SerialPort docs, it says
that the base stream is not buffered, while the SerialPort class itself
is. I would be concerned that you could potentially lose data if you
aren't careful with how you use the BaseStream, by not having an
outstanding read posted when some data comes in.

Granted, it could be I'm just misunderstanding the implementation. I
don't really know much about SerialPort or of the Stream that it uses,
and it's possible that the docs are being misleading by saying that the
stream isn't buffered (they could be talking about some kind of buffer
other than at the lowest level, for example).

Basically, while I think you ought to be able to use the Stream
methods, the docs make me wonder about that, and it seems like the
DataReceived event should provide a similar enough behavior to be
sufficient.

So, how to use DataReceived? You should not spend any significant time
in your DataReceived handler. You should read whatever bytes are
available, appending them to some buffer somewhere. If and when that
buffer represents a complete transmission, then you do whatever
processing is appropriate for a completed transmission.

Basically, just let the SerialPort raise that event repeatedly until
you've received all of the data you need. Don't do any waiting in any
thread for data per se, other than the normal waiting that occurs in
any application (waiting for user input via the normal Windows event
mechanism, for example).

Pete