[En-Nut-Discussion] Feature Request 1572837: mutex API nesting level info

[Bernard Fouché]

Nathan Moore wrote:
> Well that's exactly what they are good for.  You have not told me why they
> are bad, only
> that I'm doing stuff wrong.  I don't see anything wrong with using a
> recursive mutex.
>   

That's exactly the point: they are bad because they encourage you to do 
wrong stuff! Without recursive mutexes you would have reconsidered your 
design and discovered that you can live without them. However for quick 
prototyping they may be handy but then you have to work twice on the 
same code, once for writing the prototype, once to finalize the design.
> Ok, implement a splice with your method.
> I want to take stuff from Uart1 and output it to Uart2 up until an IO line
> goes low.
> When that happens I want Uart1 to be used by other threads to output any
> status
> messages that they may have until that IO line goes high again (which will
> likely
> cause an interrupt which will post an event).
>
>   

I think that unless real code is written like you did in your first 
example, it's difficult to provide a good answer:  in this second 
problem description, there is no specification forbidding to always 
allow threads to output to UART1, even if UART1's input is to be output 
on UART2 according to the IO line (there is also nothing in your 
description about what to do with UART1's input when the IO line changes 
of state and threads are outputing to UART1). Maybe no mutex is needed 
at all.

Note that such a splice can be difficult: if the IO line drives the 
application behavior regarding UART's, you may reach a situation where 
the IO line changes of state but there is already a character placed in 
a UART register (rx and/or tx). So you may send/receive unexpected 
characters on a UART, just after the IO line state change. (This problem 
is not mutex related at all)

That's is why there is often 'lag' when using hardware handshaking in a 
serial link: if CTS or RTS changes of state, one or more characters may 
still reach the remote party because some UART registers were set up 
with data before the detection of the change of state.

Maybe multiplexing would be a better solution? This would allow you to 
specify what is the final usage of a character and helps the remote 
party not to badly mix received characters.