I suppose my question is what do you need at the application for a “SMP Mutex” that the ordinary mutex doesn’t handle (since it WILL block a task on a core that is different then the core that tool the mutex first, there is no such thing as a “single core” mutex in FreeRTOS)? At the kernel level, there is a need as the kernel can’t “block” since it is what does the blocking, so needs the spinlock level of interlocking, and that comes with the presumption that everyone using those locks is following the internal rules for such locks (like only held for short deterministic time periods). “I/O” libraries rarely need the sort of global critical section that the kernel needs for the scheduler, and from what I have seen, people will sometimes grab the “Critical Section” from FreeRTOS just because it matches the name of a more general concept, not understanding what it actually is.
With AMP, the code for the FreeRTOS critical section is quick, and can be useful for code that needs a very low overhead protection for a very short piece of operations and thus there are reasonable uses in “user” code when that is what is needed. When you start to get into SMP modes, the cost goes up, and the fact that it becomes a GLOBAL blocking becomes meaningful, so it is much less appropriate for user operations.
I will admit that I haven’t done a lot of SMP work, and it is a fact that much of the FreeRTOS ecosystem was built in an AMP type world, but I also know that the guidelines that are used limit the use of the “critical section” to those very short operations that need to be atomic, so the extra cost in SMP shouldn’t be that bad where they are used, but things might improve as it gets more use in SMP environments and more work is done on it.
You need to remember that FreeRTOS is designed to be very generic, and usable in many environments, and is optimized for the smaller cases, not to be the most powerful for the larger case.