Note that there are some explanatory texts on larger screens.

plurals
  1. POI need to implement a way to sleep this thread until it has work to do
    primarykey
    data
    text
    <p>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.</p> <p>Here is the situation.</p> <p>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: </p> <ol> <li>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)</li> <li>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)</li> </ol> <p>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:</p> <ol> <li>Initialization</li> <li>While we have not received a shutdown command from the manager</li> <li>If our timer is up, poll the board for data</li> <li>Otherwise, check to see if we have a message posted by the manager to the queue. if so, process it</li> </ol> <p>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:</p> <blockquote> <p>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 messages over the socket to the thread. Then select() would sleep until there was activity on the fd or my timer was up.</p> </blockquote> <p>Pro: Exactly the functionality I need.</p> <p>Con: Aren't sockets a bit heavy processing for communication to a thread where you share memory already?</p> <blockquote> <p>Use a signal system. (Someone more knowledgeable in Linux can pipe up here with an implementation example... I'm not sure exactly how to do it.) But the thread could sleep for the duration of the timer, and wake up to process if a signal was received from the manager.</p> </blockquote> <p>Pro: Maintains current implementation using shared memory</p> <p>Con: Not sure how to implement. Is there a function like select() that works with signals instead of fds?</p> <blockquote> <p>Potentially a mutex. I could block until a mutex was posted to by the manager.</p> </blockquote> <p>Pro: Still sharing memory</p> <p>Con: might need to move timer processing to the manager and that really isn't an option as it has other timers and critical work to perform.</p> <p>Please recommend and feel free to critique. I am open to any efficient options. Please note though this is running on an embedded system, so resources usage is critical.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload