SerialPort: DataReceived thread ...

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.

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

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.