[PATCH v2 5/5] score: Add deadlock detection

[Sebastian Huber]

On 27/07/16 06:51, Chris Johns wrote:
>>
>> +#if defined(RTEMS_SMP)
>> +/*
>> + * A global registry of active thread queue links is used to provide 
>> deadlock
>> + * detection on SMP configurations.  This is simple to implement and no
>> + * additional storage is required for the thread queues.  The 
>> disadvantage is
>> + * that this global registry is not scalable and may lead to lock 
>> contention.
>
>  The disadvantage is the global registry is not scalable ...
>
>> + * However, the registry is only used in case of nested resource 
>> conflicts.  In
>> + * this case, the application is already in trouble.
>> + */
>
> How does a user know this or detect there maybe an issue? Is there a 
> flag, count or something else kept that says there is a problem and so 
> an application problem?
>
> Writing apps for real-time SMP is something new and difficult and it 
> would good to provide users with relevant indications when things are 
> not going well.

The deadlock detection is just the first step in implementing the OMIP 
protocol. It will get more complex and I guess there will be a 
considerable worst-case overhead for applications with complex resource 
dependencies. Avoiding complex resource dependencies must be done in the 
design phase of the application.

The worst-case run-time is determined by the resource dependency graph. 
Once the implementation is done I will add some documentation with the 
implementation details. I think this should go into the user manual in a 
dedicated section. Its important for the user to know the run-time 
complexity of mutex obtain and release operations for example from my 
point of view.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.