Hi Roberto,

Thanks for the reply and the suggestions.  I'm very nervous about giving myself a threading waver too! :-)

I am leaning towards an independent process/app to handle just the serial comms and exchange that will communicate via some IPC mechanism with my main application.

There are some messy aspects no matter how I proceed.

- If I leave things as is, I have to live with some long program pauses and because this is a real time sensing and control application, that leads to some less than optimal results at time.  On the plus side I keep a straight linear application that is easy to understand and maintain.

- If I go with a threaded solution I maintain potential portability to embedded systems that are not unix based and perhaps only support a single process (with multiple threads.)  But of course all the pitfalls of threads and long term maintainability apply.  And there are many misunderstandings of threads and what they can do.  I've seen times that a thread blocking on IO can block the entire application anyway.  Certainly a thread that crashes or executes a bad instruction will kill the entire application.

- If I go with a separate application, I push myself towards linux based systems only, or systems with advanced kernels that support multiple concurrent processes.  There are also so possible messy startup issues to think through (I have to start multiple processes rather than a single process, although one process could launch the other I suppose.)

I also have to decide what IPC mechanism to use ... I like the idea of using sockets, partially due to existing available socket communication mechanisms already built into my code and it fits the FIFO nature of my task pretty well.  I spew data packets out and I don't care if random packets are dropped or corrupted (as long as an appropriate amount get through for the bandwidth of my serial link.)  And the return data is infrequent "commands" which might be more appropriate as a stream socket connection (which I already have support for in my code.)

Best regards,


On Sat, Aug 28, 2010 at 7:23 AM, Roberto Waltman <fsim@rwaltman.com> wrote:
Curtis Olson wrote:
 > This is a little off topic, but I don't know where else I can find a
 > stronger knowledge pool. :-)
 > I am working on some code that needs to read and write from a serial
 > port and has to write vast quantities of data ...


I wouldn't use threads, but a whole separated process.
Use circular buffers in shared memory to transfer data, and semaphores
to coordinate data transfers in/from these buffers.
That way your main process only needs to do non-blocking memory to
memory transfers.
The serial coms process can handle all the quirks of the protocol,
create separate Tx and Rx threads if necessary, decide when to drop
data, block itself when needed etc.
One of the advantages of using a separate process vs threads in the main
application is fault isolation. (1)
The unavoidable crashes during development may bring down only this
process, allowing you to continue by restarting only this part and not
the whole application.
The same applies if you want to try a different version. Stop the
subprocess, start a new one.

Hope this helps,

Roberto Waltman.

(1) I worked for a company whose coding standards required a manager's
waiver to use threads, because of the difficulties of debugging complex
multi-thread applications where every thread can corrupt global data.
And the fault isolation.

Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
Flightgear-devel mailing list

Curtis Olson: http://baron.flightgear.org/~curt/