aboutsummaryrefslogtreecommitdiffstats
path: root/docs/src/lifecycle.dox
diff options
context:
space:
mode:
Diffstat (limited to 'docs/src/lifecycle.dox')
-rw-r--r--docs/src/lifecycle.dox67
1 files changed, 67 insertions, 0 deletions
diff --git a/docs/src/lifecycle.dox b/docs/src/lifecycle.dox
new file mode 100644
index 000000000..d96795b21
--- /dev/null
+++ b/docs/src/lifecycle.dox
@@ -0,0 +1,67 @@
+/*
+ ChibiOS/RT - Copyright (C) 2006,2007,2008,2009,2010 Giovanni Di Sirio.
+
+ This file is part of ChibiOS/RT.
+
+ ChibiOS/RT is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ ChibiOS/RT is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>.
+*/
+
+/**
+ * @page article_lifecycle Threads Lifecycle
+ * In ChibiOS/RT threads are divided in two categories:
+ * - Static threads. The memory used for static threads is allocated at
+ * compile time so static threads are always there, there is no management
+ * to be done.
+ * - Dynamic threads. Dynamic threads are allocated at runtime from one of
+ * the available allocators (see @ref heaps, @ref pools).
+ * .
+ * Dynamic threads create the problem of who is responsible of releasing
+ * their memory because a thread cannot dispose its own memory.<br>
+ * This is handled in ChibiOS/RT through the mechanism of "thread references",
+ * When the @p CH_USE_DYNAMIC option is enabled the threads becomes objects
+ * with a reference counter. The memory of a thread, if dynamic, is released
+ * when the last reference to the thread is released while the thread is in
+ * its @p THD_STATE_FINAL state.<br>
+ * The following diagram explains the mechanism:
+ * @dot
+ digraph example {
+ rankdir="LR";
+ node [shape=circle, fontname=Helvetica, fontsize=8, fixedsize="true", width="0.75", height="0.75"];
+ edge [fontname=Helvetica, fontsize=8];
+
+ init [label="No thread", style="bold"];
+ alive [label="Alive"];
+ final [label="Terminated"];
+ detached [label="Detached", style="bold"];
+
+ init -> alive [label="chThdCreateX()"];
+ alive -> alive [label="chThdAddRef()"];
+ alive -> alive [label="chThdRelease()\n[ref > 0]"];
+ alive -> detached [label="chThdRelease()\n[ref == 0]"];
+ alive -> init [label="chThdWait()\n[ref == 0]"];
+ alive -> final [label="chThdExit()\nreturn"];
+ final -> final [label="chThdAddRef()"];
+ final -> final [label="chThdRelease()\nchThdWait()\n[ref > 0]"];
+ final -> init [label="chThdRelease()\nchThdWait()\n[ref == 0]"];
+ }
+ * @enddot
+ * <br>
+ * As you can see the simplest way to ensure that the memory is released is
+ * that another threads performs a @p chThdWait() on the dynamic thread.<br>
+ * If all the references to the threads are released while the thread is
+ * still alive then the thread goes in a "detached" state and its memory
+ * cannot be recovered unless there is a dedicated task in the system that
+ * scans the threads through the @ref registry subsystem and frees the
+ * terminated ones.
+ */