Actually that does happen.
Even when using a PC keyboard, you will start to get beeps from the machine when the keyboard buffer fills and no more input is accepted.
This was more common back in the old DOS days since the DOS and the BIOS were so crude. i.e. if the app crashed or got really slow or hung up, this would happen.
For your queuing in this project, the simplest thing to do is to set your shared variables to volatile and then mutex their access and updates in the foreground code.
(i.e. block interrupts when messing with them)
All this other stuff in the discussion, is when the code is trying to get fancy for some reason (or being careless) and not using the standard and reliable mechanisms to protect the threads from each other when accessing shared data/variables.
Once that works, if there is some underlying performance need, you can look at some more sophisticated ways to handle the shared data.
But in general, the other ways that avoid using normal locking and volatile mechanisms are not going to be a miracle bump in performance. It typically will only offer slight improvements which is why it is often not worth going after.
To get a big bump in performance, you will need do something differently in the system. i.e. change bus speed, run a different communication protocol, change when/how messages are processed, remove/change other code in the system that is adding timing overhead such as outputing information to display less often, etc...
big/other stuff like that is where you will get the biggest performance/througput gains.
--- bill