Hello again.
Still using FreeRTOS (preemptive multitasking) on STM32F103VE and GCC. If I have two tasks of equal priority, both of them are blocked, and then another task gives two different samaphores, one unblocking fist task, another – unblocking second.
In which order will sheduler choose tasks to enter running state? This is essential for me, because both of these tasks are accessing shared peripheral (DMA), so if sheduler will always choose, for example, first one, then this task will block DMA, and second, after switching to it, will just block again on new semaphore. Here is an example:

xSemaphoreHandle DataSent; //New data arrives with acknoledge of success transmit,
xSemaphoreHandle NewDataArrived; //so thees two are given simultaneously
xSemaphoreHandle DMAFree; //Controls access to DMA
//....
static void taskIRQHandler(void *pvParameters) //not ISR, just high priority task
{
  //...
  xSemaphoreGive(DataSent);
  xSemaphoreGive(NewDataArrived);
 //...
}
static void taskTx()
{
//..
   xSemaphoreTake(DataSent);
   xSemaphoreTake(DMAFree);
//...
}
static void taskRx()
{
//..
   xSemaphoreTake(NewDataArrived);
   xSemaphoreTake(DMAFree);
//...
}

With respect to each other, the task that is unblocked first will run before the task that unblocked second.  That is not a good way or architecting the system however, because the two tasks are of equal priority, you can make no guarantees about how far the task will get through its code before a context switch to the other task will occur.  If it is essential that one task executes to a certain point before the other task executes then it should be assigned a higher priority than the other task. Regards.

Thanks again!
Yes, I thought about making RX task’s priority higher than Tx, but then changed my mind.
It may cause Tx FIFO buffer of tranciever get empty, because instead of posting new data, system will continue reading Rx FIFO.
Ideal case, I suppose, is reading one Rx FIFO item (if available), then posting one Tx FIFO item, and so on.
So, may be, I’ll make just one diver task for transmitting an receiving, instead of two separate, and will switch between Rx and Tx activity manually.

*dRiver task, ofcourse)

First, it isn’t THAT bad for the second task to start to shortly hit a second block on the DMA not being free. Unless you are really tight on CPU resources, A second option might be to have taskIRQHandler only give 1 semaphore (the one to the task you want to run first), after setting a flag to that task to tell it that when it is done, as well as giving the DMA flag, to give the other task flag.  This does add complexity and coupling between tasks, so I would only do this if you can show that the performance of allowing the possible extra block is significant. Note that if the first task to start normally would run to the point of giving the DMA semaphore without blocking, and takes significantly less time than a timer tick, most of the time the second task may actually never get started until the semaphore is free, and you don’t pay the cost of the block normally. If the first task normally has to block during its operation between taking and giving the DMA semaphore, so the second task does run and block, then the time for the first task to be blocking generally will override the cost for the second task’s block, making it  insignificant. 

richard_damon, you are probably right about “isn’t THAT bad for the second task to start to shortly hit a second block on the DMA not being free”, because when traciver is in half-duplex mode (awaiting acknoledge after each transmission before asserting  DATA_SENT_IRQ), interval between two interrupts are much longer than it takes to receive payload and transmint next package via DMA. But I am actually is stuck on another problem, there is terrible bug in blocking, (here is my question about it https://sourceforge.net/projects/freertos/forums/forum/382005/topic/5113026)
and I can not continue working with Tx/Rx – just sucking in Tx. I’ll appreciate if you’ll take a look.