We have had this many many times before: IF you insist in accessing a UART from multiple tasks, use muteces, that is what they are for.
But keep in mind that this control flow normally is a poor model of what a UART is about. As the name implies, a UART is an inherently serialized device, and the better way to model this is through a single task that services the device, itself being presented the data to transmit/receive by client tasks via IPC (typically queues). That makes mutual exclusion unnecessary. Everything else is but a pandora’s box of problems.
Most likely the protocol you are supposed to implement is a half duplex/response-request protocol where some entity of your system sends a request and immediately afterwards waits for a response from the peer. In that case it seems natural to “atomize” each transaction via a mutex and let each of several tasks process their respective transactions concurrently.
I promise you that you will regret that design. It bears many many pitfalls.