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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
