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,
Curt.
On Sat, Aug 28, 2010 at 7:23 AM, Roberto Waltman <f...@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 ...
>
> Curtis,
>
> 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.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
