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

Chris Johns chrisj at rtems.org
Wed Jul 27 06:15:44 UTC 2016

On 27/07/2016 15:45, Sebastian Huber wrote:
> 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.

I am sure it will get more complex and those developing applications 
will have bugs while they are developing. If we have a way of flagging 
something is wrong it will help. If something happens which should not 
it is a good feature for an OS to flag it so a user can inspect and see 
everything is OK and if wrong they need to do more work.

> 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.

That would be fantastic. I will keep working to get the 4.11 doco branch 
created so you have something to work with.


More information about the devel mailing list