SerialPort: DataReceived thread ...

[Jamie Risk]

What thread does the DataReceived event run on?

I'm preparing a design that uses the DataReceived event to
stimulate a protocol state machine (PSM). The ambition is to
have the serial process happen in the background, and when
certain conditions are met, the PSM then triggers an event
(myPacketIsHere for instance).

The PSM will only ever deal with the serial data sequentially,
i.e. through the use of locks and such, only one instance of the
PSM will run at any given time.

My questions then are:
* What thread does the DataReceivedEventHandler run on?
(Is it from the threadpool?)
* What's the best practiced method for having an event
handler keep state information between successive calls?
* When the PSM triggers its own event, what thread is the
event handler for that going to be running on.
(myPacketIsHereEventHandler())

If it isn't obvious that I'm weak on Delegates, and Threading,
I apologize ... the fact is I am.

- Jamie

 

[Dick Grier]

Hi,

The DataReceived event executes in the (background) thread context of the
SerialPort receive thread. All code called directly from the DataReceived
event executes in the background tread context.

You can keep state information in any suitable structure. Typically a set
of private (perhaps shared) variables, or in an object (Class, so that you
can encapsulate both data - states - and methods and events that might be
called depeding on state) that you might instatiate when you open the port
and begin communications. If you create an object to handle the PSM, it may
use either the background thread of the DataReceive event, or it can
delegate operations to a separate background thread.

The more threads used, the more complex becomes debugging. And, usually,
additional threads will not provide any improvement in performance or
maintainability (IMO).

BTW, the object method for creating a state machine is the approach that I
prefer, unless the number of states is fairly small. Realize that if your
DataReceived code or code in the PSM interact with the User Interface
(STAThread), then this interaction must be marshaled to the UI thread via a
delegate (Invoke or BeginInvoke).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Jamie Risk]

Thank you for the response. I have two more questions.

The DataReceived event executes in the (background) thread context of the
SerialPort receive thread. All code called directly from the DataReceived
event executes in the background tread context.

What about events published by the DataReceived handler. On
which thread are those events picked up? Will these be a
background thread as well?

BTW, the object method for creating a state machine is the approach that I
prefer, unless the number of states is fairly small. Realize that if your
DataReceived code or code in the PSM interact with the User Interface
(STAThread), then this interaction must be marshaled to the UI thread via a
delegate (Invoke or BeginInvoke).

I'm not sure what you mean by "the object method for creating a
state machine". Could you elaborate with, perhaps a pointer to
some reading material?

- Jamie

 

[Dick Grier]

Hi,
What about events published by the DataReceived handler. On
which thread are those events picked up? Will these be a
background thread as well?
<<

Yes (unless these events are specifically generated by code in a different
thread).
I'm not sure what you mean by "the object method for creating a
state machine". Could you elaborate with, perhaps a pointer to
some reading material?
<<

What this means is that you create a class that implements all of the
features of your FSM (instead of inline code). Then, you create an instance
of that class when you start your program, perhaps when you open the port.
Methods in the class might send commands, wait responses, or process serial
data via a method that is called from the DataReceived event, where you pass
it the serial data that generated the event.

The class itself would have data that represents state (private variables)
and data that represent results that you want to relay to the calling
code -- and events for notification. Unless this class creates a seperate
thread (and it probably won't), any event notifications based on
DataReceived data will execute in the thread context of the background
thread.

I have a FSM that decodes GPS data (for example) in my book that uses this
form. I'm sure there are others around. However, these sort of things tend
to be "designed for a purpose" and while useful as guides will be just that.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.