Stephen Nuchia wrote:
So is there no way to create a thread and not have it take up all the CPU time until it's done without using SMP? (This is going to be for carputers, so it won't be in an SMP environment.)
Now that you've clarified your intended purpose, it is apparent that your simple producer/consumer test program was not a good model of the real program.
I'm beginning to see that, mainly because, as I read the posts, I'm realizing that there are a lot of low-level issues that I hadn't expected. I'm used to Perl or Java where all that is taken care of. Back in the 1980s I used to program in Assembler and deal with low level issues, but that was on a 6502 (Apple //e), so I never dealt with any issues in terms of threading.
How the threaded serial port monitor will work in your production environment is something you'll have to experiment with. If the target environment has good support for threads and a fairly high-level driver for the serial port then simply assigning a higher priority to the port monitor thread should work. But it may be necessary to use an interrupt-based solution instead.
I was (and still am) hoping it doesn't get to dealing with interrupts. That's a whole different topic and I'm quite new to C++. This kind of programming for me, in any language, is rare. I hardly ever have to deal with the hardware issues. In this case, I didn't realize how important waiting on the serial port could be.
The normal paradigm for threads on a uniprocessor is that the highest-priority runnable thread runs until it is no longer the highest-priority runnable thread. That can happen when 1) It blocks, either for I/O or on a mutex or 2) The priority of that thread or another thread is changed or 3) Some higher-priority thread becomes runnable (I/O completes, interrupting event occurs, or mutex freed). 4) If more than one thread is runnable at the highest priority, the system may time slice among them at some fairly low frequency (10-1000 ms typically). 5) In non-realtime unix environments, such as the one in which you are experimenting, there is a dynamic priority adjustment scheme at work that is designed to give good interactive responsiveness under load. This scheduler protocol is often not suitable for realtime applications.
By non-real time, you mean the demo program, right?
Time slicing more frequently would impact efficiency because the context switch itself takes time and the new thread will want a different working set in the cache, leading to a lot of unnecessary memory traffic. You may want to pay that price for simulation purposes but in general you don't want it. See others' comments about inserting sleep commands if you want to simulate multiprocessor behavior.
After looking over what I've learned (and thanks to all, because this thread on threads has been an education in itself), I don't think the threads and timing will be an issue because the one reading from the serial port will be blocked most of the time (it never seems to get more than 256 bytes at a time and rarely more than 40 at a time) and when it isn't, I can use nanosleep as it processes to make sure it never hogs resources. That should make that thread almost invisible in terms of the time it consumes. (Is my reasoning right on that?)
Ideally, your production program's port monitor thread would run at high priority but spend most of its time blocked waiting for input. When a frame becomes available the hardware should interrupt the driver, leading to your thread becoming runnable. When the OS returns from the driver's interrupt service routine your input thread should then run until it loops back to wait for more input. If you haven't signaled any semaphores the previously running thread resumes at that point. If you did signal data available a different thread may be scheduled.
I don't need to signal data available, at least as far as I know. I may by simply changing a boolean flag.
I've built several systems on this principle very successfully but you have to know your OS and compiler and hardware cold to get reasonable performance and reliability.
That's the hard part. This is working at a low level I haven't worked at for about 20 years and when I did, there was no multi-tasking and no issues like this. (Sometimes I still year for days when I was working on simpler 8 bit systems!) Hal