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

Reply via email to