Hi, On Thu, 16 Nov 2006, TH & CD Maher wrote:
> > In generic terms how does one partition threads such that certain > threads can only access the variables relevant to such threads? > > effort. 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. An existing C++ application that generated some web pages describing how it was operating, which accepted user input from the web pages. It also read/wrote data from/to the sound card, compresed/decompresed with a library codec, and sent/received compressed audio packets over the ethernet... This program is tested, verified , and known to work correctly. They wanted a serial interface added, which would read in serial messages (on average, one per every 4 seconds, each 10 bytes long) and some processing of the messages, and then transmit the message out an ethernet port. 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. *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. The main program would, on generating the web page describing how the serial functionality was working, access those public methods to report on status. The two threads existed in the same class. They accesed three variables in common - list of strings, flag to indicate if they should keep going, and the signal. Each of these three variables is thread safe. This object was written so as not to touch the variables in the main program. See - there is a clear partioning of what each thread touches. Indeed, there is the minimum of locks here because so few things are in common. Well, yes, I could have put this serial ethernet into a separate program. However, that would have made it hard to integrate the status reports from this serial ethernet into the web page of the main program. I was forced to use two threads to do the serial read and processing. Suppose the read step had read one message, did the processing (and was delayed) then there could have beeen two messages sent to the port that we missed. Remember, the serial port is not big enough to buffer the messages..... And, the customer wanted every message from the serial port. Since this application is running as a background process, with root priviledges, I could set the priority of the serial read process to high, giving a better chance of reading all messages. Well yes, I could have done the serial read and processing with one thread. At every step in the processing, jump back and check for messages. Sounds like additional work for the computer, and the code is not as clear. 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. Did you remember the first criteria - in the minimum of time? =============================================== O.k, now here is the challenge. I have laid out my solution. Would the no threads people like to lay out their solution? Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] ph +64 3 365 6485 Web: http://www.indranet-technologies.com/
