On Fri, 17 Nov 2006, Derek Smithies wrote:
Here is a problem I was faced with, and needed to solve in the minimum of time, with the minimum of chance of breaking other things.
Hmm. There is one thing I note there. The word "I". Multithread solutions definitely start to go downhill when it becomes "we" or "you and yourself a year later"....
I created an object to do all of this. Inside the object there were two threads. * The first thread read data from the serial port, then put each message onto a threadsafe list of strings. After reading one mesage, it signalled the second thread to check for data.
"threadsafe list of strings" In the world of cow&fork, it is called a pipe :-) and comes with the OS.
*the second thread waited for the signal. On receipt of the signal, it stripped all available messages from the thread safe list of strings. Then, it did the required processing on each string read, and then transmitted it. This object had several publically available thread safe methods to report status, message counts, last error messages.
There is a rich set of IPC tools to do this. Even distribute the task over the 'net.
Well, yes, I could have gone through and bastardised/butchered the rest of the program to check for and process the serial messages. And no extra threads are required. Sounds like a lot of work to me. The rest of the program is tested and working fine - leave it alone. Actually, it would have been a real butchery job - the codec libraries needed modification to check the serial port for messages.
Nah. Spin a process to handle the real time low latency stuff, and use one of the many handy IPC mechanisms to poke the codec as needed. The nice thing is you can be certain, now and in the future that nobody is mucking with the shared data, just because "they thought it was OK".
Did you remember the first criteria - in the minimum of time?
Yup, a nice small self contained additional program you can test and exercise by itself. Make it work, then integrate it with Big Brother. Big brother can just create the appropriate IPC and then fork the new little program.
O.k, now here is the challenge. I have laid out my solution. Would the no threads people like to lay out their solution?
John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : [EMAIL PROTECTED] New Zealand
