How to repeat xQueueSendToBack atomically?

Hi all, In my FreeRTOS project, I want to post several messages to queues (from task) without the possibility of a task switching until after the group of sends. I have implemented it using vTaskSuspendAll, but this appears not to work.
Here is pseudo-code of the section (which is called from a task not ISR):
  vTaskSuspendAll(); 
  for (i = loop through routing table)
  {
    if (route exists)
    {
      os_err = xQueueSendToBack( queue[i], &blockToSend_p, 0 );
      num_routes++;
    }
  }  
  blockToSend_p->num_references = num_routes;
  xTaskResumeAll();
At xTaskResumeAll I have a situation that the highest prio task shown as READY in StateViewer is *not* the one that is scheduled next.
I am aware that the FreeRTOS documentation for vTaskSuspendAll/xTaskResumeAll specifies not to use certain RTOS calls including xQueueSendToBack while suspended; however my understanding is that one may not make calls with potential to block. Using delay 0 in ‘send’ ensures the call does not block. What should I concluded from the unexpected sheduling behaviour?
A. I’ve used the wrong design.
B. It’s the right design, but a stack overflow is breaking the RTOS.
I tried placing a taskYeild() after xTaskResumeAll() but it did not fix my crashes.
Should I consider using xQueueSendToBackFromISR from task in order get queue-but-don’t-reschedule behaviour?
My setup: STM32F103,  FreeRTOS 7.0.2,  IAR EWARM 5.30 with StateViewer plugin. Many thanks for your suggestions. Owen

How to repeat xQueueSendToBack atomically?

I’m not sure if xQueueSendToBack() can be used when the scheduler is suspended, it might even depend on the port being used, but if it says not to do it then it is probably best not to. As an alternative, try temporarily raising the priority of the task doing the sends to be above any of the tasks doing the receives, then when all the sends are complete, drop the priority back down again and the receive tasks can then run.

How to repeat xQueueSendToBack atomically?

Thank you for that suggestion.  I had
#define configUSE_PREEMPTION        0
and this may have been the issue, but the build has other bugs that are not yet resolved.
So I will report back a solution when the other bugs are fixed.