The solution I can see is to make the process talk through notifications handevent loops
In anyway somewhere you have a thread asking for a frame's data. In anyway you will have a delay of at least the side of the processing window (perhaps 64-2048 frames, depending on what you have chosen). What I can see is that you just need to have an event loop for the rendering process. Once something happen in what you call processor A or B you will add an event to the event loop of the rendering process. The rendering process prior to filling the rendering window with data, will look at the events it does have to consider. If some "processor" A or B sent events like addEventToNextFrame(positionOfTheEvent); then the rendering window will just add this event at the given position. Again in audio processing you are always working with a delay, it might be a one sample frame but this is still a delay (and most of the time uncommon). You can report the delay or not. What I mean is when an event will occur on your processor A (or B), you can either choose to add an event as soon as possible in the next rendering frame (setting the event offset to 0) or report the delay when the event occured in the current frame to the next frame which will be the rendering frame to render.
If your data are not events but audio samples, it's your responsibility to ensure the next buffer will be fed before the rendering comes. A way of doing this is to have a event loop into your processors A and B and to be notified from the rendering thread when it ended to render all the stuff. In this way your threads A and B are just filling a buffer and wait for an event "fill next buffer" to start doing the job again.
To make it short, each processor A and B (threadsA and threadB) start doing their job looking at the events to process into the eventLoop. If there is something like fill the next rendering (output) buffer, they will do so then post the result as en event to the rendering thread. The rendering buffer at the time it will have to render the frame will look at it's events. In those events, he might have the data content of what threadA and theadB did. Once done with the processing, the rendering process will notify the threadA and threadB by another event telling them okay I'm done, you can fill my next buffer.
In that manner : All the process can talk together and in the destination thread (most important), no risk of being locked by one. It is just a little complex to understand but I'm using this almost everyday.