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

[Przemek Rudy]

Hi,
Sorry for the delay.

The story with this mutex is pretty simple:
There is a function that calls the mutex. This function can be called 
recursively. But only for the first nested call an additional action 
must be made. Thus the simplest way for this is to check the mutex value 
just after taking it.

This is not for the debug. There is obviously no problem taking the 
mutex value directly, but accessing internal data structures is a hack 
in my opinion. On the other hand there is no big pain giving this value 
back with public API.

Thanks
Przemek


Matthias Ringwald pisze:
> I've posted in the tracker to ask what it is used/needed for.  
> Otherwise I would agree with Nathan that it's probably for debugging  
> purposes.
> 
> Hi
> 
> adding the return statement would not be hard. But why do you want  
> this? I assume it could be used to write some asserts.
> Would directly accessing mutex->count be very inconvenient in your case?
> 
> matthias
> 
> 
> On 09.07.2008, at 16:31, Nathan Moore wrote:
> 
>> I believe that what you would actually get back is how many times the
>> current thread has called NutMutexLock on a particular lock.
>> The nesting of these mutexes is so that if a function like fputc  
>> were to
>> lock the file's mutex around it's operation, and then fputc was also  
>> called
>> by fprintf which needed to keep all of it's output together it could  
>> also
>> lock the file's mutex without worrying about blocking fputc being  
>> blocked or
>> releasing the lock prematurely.
>> Returning the count might offer some debugging help (ie  
>> "NutMutexUnlock just
>> returned != 0 at what should have been top level"), but I don't see  
>> how
>> useful it would be in production use.
>>
>> Nathan
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
>