I am not sure how I would handle the stuff in this case. I guess I would assemble the message completely before sending it by rs232?

It's not really possible for me to respond to that (hypothetical?) question without knowing a lot more detail about the application; the protocol(s) and what these "some more threads" might actually be doing.

From a very generic design viewpoint, I generally consider it "bad form" to communicate multiple types of data, or many to many conversations, via a single queue. If you've ever taken part in multi-way, conference calls -- especially intercontinental ones with the added bonus of satellite lag -- you'll understand the problem many to many conversation have.

Queues are relatively cheap structures -- provided they cannot be subject to runaway producer growth -- and I have no problem with using as many as I need. One (producer) to many (consumers) or vice versa is fine -- bread and butter stuff -- provided that all of the 'many' in either scenario are clones doing the same thing, each being equally capable of being the sink (or source) of any message appearing in the queue.

The moment you start being selective about what you will receive from a queue, you've broken the basic tenets of what a queue is and is useful for.