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

[Bernard Fouché]

Hi,

FYI, here is the point of view of eCos designers about recursive mutexes 
(taken from http://ecos.sourceware.org/docs-latest/ref/kernel-mutexes.html):
---


    Recursive Mutexes

The implementation of mutexes within the eCos kernel does not support 
recursive locks. If a thread has locked a mutex and then attempts to 
lock the mutex again, typically as a result of some recursive call in a 
complicated call graph, then either an assertion failure will be 
reported or the thread will deadlock. This behaviour is deliberate. When 
a thread has just locked a mutex associated with some data structure, it 
can assume that that data structure is in a consistent state. Before 
unlocking the mutex again it must ensure that the data structure is 
again in a consistent state. Recursive mutexes allow a thread to make 
arbitrary changes to a data structure, then in a recursive call lock the 
mutex again while the data structure is still inconsistent. The net 
result is that code can no longer make any assumptions about data 
structure consistency, which defeats the purpose of using mutexes.
----

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.

For instance having a 'void *' pointer inside NUTTHREADINFO 
<http://www.ethernut.de/api/struct___n_u_t_t_h_r_e_a_d_i_n_f_o.html> for 
application use (a 'HANDLE'). That was quickly discussed a long time ago 
("Per thread global variables" circa 18/10/2005 and 19/10/2005) but I 
don't think that this idea made its way yet into NutOs code.

With this feature, and using a 'struct' to hold whatever data a thread 
needs to handle at the thread level, a thread could easily remember if 
it has already locked some mutex and need not do it yet another time. To 
implement this we would need a new API call like 
'NutThreadSetApplicationDataPointer()' (a better name is welcomed).

When the thread is started, then the developper would malloc() a 
structure holding what he/she needs to manage mutexes and whatever other 
required info, initialize it, and then call 
'NutThreadSetApplicationDataPointer(<malloc'ed struct pointer>)'.

NutThreadDestroy(), seeing that this pointer is not null, would 
automagically free it before completely releasing  the thread. The 
application data pointer would be accessed in application code thru 
'NUTTHREADINFO *runningThread' or a particular #define'd constant to 
ease code reading.


    Bernard

Alain M. wrote:
> Hi,
>
> I was checking with a friend who has a better understanding of those 
> matters:
>
> Neither os us have eve known of a mutex that can be locled more than 
> once on the same thread just because the thread lock on the first atempt 
> if it is not available.
>
> Also never heard of a Semaphore that is not thread-aware.
>
> I was wrong about using Semaphores as counters, this is a non-standard use.
>
> The "normal" way of controling re-entrancy is to have a mutex + a 
> counter, no standard simpler way. In Nut, NutEnterCritical() can be 
> lighter, but it may depend on the application.
>
> My vote: use only what is standard and well known to every one. (This 
> has already been Nut's way for long...)
>
> Alain
>
> Przemek Rudy escreveu:
>   
>> Matthias Ringwald pisze:
>>     
>>> ...
>>> semaphore. Even more, a semaphore initialized to one cannot be aquired  
>>> a second time, even if its by the same thread. that's why the  
>>> recursive mutex is good for, it allows repeated locking by the  same  
>>> thread.
>>>       
>> Yes, that is the reason...
>>
>> So I see just up to two questions that need to be answered:
>> 1. If to follow posix or not:
>> [yes] - do not change anything.
>> [no]:
>> 2. if the returned mutex counter is useful:
>> [yes] - then change mutex code
>> [no]  - do not change anything.
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>>     
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>