title: RTOS architecture design good practice
body: <p>I need some sound advice about the architecture design of a RTOS system. Let me start by explaining a bit the context. The device we're developing this software for is a bread oven which is controlled through a visual interface (GUI). Among others, we're using one thread for the whole GUI and another one for what we call the 'control', a task charged to compute the important control values (temperature,…) and to send them to another PCB (dealing with the actual hardware) through Modbus. Obviously, other tasks are running too, like one to read/write to a USB stick or another one for the Ethernet communication… The control task has the highest priority of all.</p>
  
  <p>In order to seperate the threads and make them as independent as possible, we plan to send messages between them as much as possible instead of sharing resources. Now comes my doubt :</p>
  
  <p>When a key or a button on the visual interface is pressed a sound has to be played. I thought about doing it by sending a message 'play sound' from the GUI thread to a thread of low priority that would deal with the speaker but my colleague instilled doubt in me. She said the whole process may take too long (as the speaker thread may have to wait for other threads of higher priority to finish) and that it'd be noticeable and unpleasant for the user in that case (ofc, you expect to hear the sound as soon as you've hit the key). Therefore she suggests we call a low-level function from the GUI thread to play that sound. Is it a recommandable idea? How is it usually done in the 'industry'? </p>
  
  <p>Thanks in advance for your enlightement. I know it's a very specific question but it's difficult to find any relevant information about this online.</p>