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.dox68
1 files changed, 0 insertions, 68 deletions
diff --git a/docs/src/lifecycle.dox b/docs/src/lifecycle.dox
deleted file mode 100644
index 18875e7da..000000000
--- a/docs/src/lifecycle.dox
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- 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:
- * - <b>Static threads</b>. The memory used for static threads is allocated at
- * compile time so static threads are always there, there is no management
- * to be done.
- * - <b>Dynamic threads</b>. 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 become objects
- * with a reference counter. The memory of a thread, if dynamic, is freed
- * 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 easiest way to ensure that the memory is released is
- * to make another thread perform 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, scanning the registry
- * has the side effect to release the zombies (detached and then terminated
- * threads).
- */