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

[Nathan FakeLastName]

>
> IMHO if a thread locks a mutex, then the thread can remember that fact
> in its own set of variable and avoid a new lock attempt.
>
> The problem then becomes 'how to ease 'per thread globals' management'
> for the programmer.
>
> It would be handy to be able to 'attach' a data structure to a thread to
> ease management of 'globals' for a particular thread.


Well a thread may lock an arbitrary number of recursive mutexes at any given
moment,
and adding more and more data to the thread info struct and processing this
info could get
heavy. The current implementation uses O(1) memory (the wait queue memory is
just the
thread's data that's allocated anyway) and the only operation that takes
more than O(1) time
is NutMutexLock when someone else already has the lock.  Then the current
thread is added
to a queue (this is just NutEventWait) which takes O(number of waiting
threads).
Also, the current implementation (as well as the proposed return value
changes) is
completely optional and non-intrusive on other parts of NutOs.

The whole idea is that within any function a programmer only needs to worry
about if she
has matched up the local locks and unlocks and never ever have to think
about what
called functions might lock and unlock, and just assume that those functions
have also
matched up the locking and unlocking of all recursive mutexes that it might
have used.

Nathan