Alright, so this question isn't exactly about thread management... well, sort of. I am looking for different solutions to this configuration. I have a few ideas, but am looking for any solutions that could satisfy the problem. And will weigh the pros and cons to implement the best one.
Here is the situation.
I have a manager application that will spawn a threads. This thread will continuously run and handle serial communication with boards that are connected to the system via USB. The manager application facilitates communication between other applications running on the system and this thread. The thread needs to really perform two things:
- Poll the boards for sample data via serial on a variable timer.. usually about once a minute (the serial bus is rather slow, baud is 4800. I can't control this)
- Facilitate communication with the manager application. (i.e. other applications will request sample data, the manager forwards the request to the thread. the thread performs the operation and returns the data)
My initial design was a simple one and works. I use a queue and a mutex for manager to thread communication. So the logic of the thread is as follows:
- Initialization
- While we have not received a shutdown command from the manager
- If our timer is up, poll the board for data
- Otherwise, check to see if we have a message posted by the manager to the queue. if so, process it
The problem is I did not consider CPU utilization. 99.9% of the time my thread is processing nothing and just sucking up power. I need to implement a way to sleep this thread until it has work to do. So a couple ideas:
Use select() to block. This can block based on the timer I need to use, and I could change the queue messaging implementation to socket messaging. So instead, the thread would open a client socket to the manager and the manager would pass the messa