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.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
