Fixed bug 3069854, fixed documentation article about events.

git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@2180 35acf78f-673a-0410-8e92-d51de3d6d3f4

4 files changed, 54 insertions, 49 deletions

diff --git a/docs/reports/STM32F103-72.txt b/docs/reports/STM32F103-72.txt
index dc2337f4c..1cac6cfe3 100644
--- a/docs/reports/STM32F103-72.txt
+++ b/docs/reports/STM32F103-72.txt
@@ -5,8 +5,8 @@ Settings: SYSCLK=72, ACR=0x12 (2 wait states)
 

 *** ChibiOS/RT test suite

 ***

-*** Kernel:       2.1.0unstable

-*** GCC Version:  4.5.0

+*** Kernel:       2.1.2unstable

+*** GCC Version:  4.5.1

 *** Architecture: ARMv7-M

 *** Core Variant: Cortex-M3

 *** Platform:     STM32 MD

@@ -95,55 +95,55 @@ Settings: SYSCLK=72, ACR=0x12 (2 wait states)
 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.1 (Benchmark, messages #1)

---- Score : 252041 msgs/S, 504082 ctxswc/S

+--- Score : 248573 msgs/S, 497146 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.2 (Benchmark, messages #2)

---- Score : 204649 msgs/S, 409298 ctxswc/S

+--- Score : 201227 msgs/S, 402454 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.3 (Benchmark, messages #3)

---- Score : 204649 msgs/S, 409298 ctxswc/S

+--- Score : 201227 msgs/S, 402454 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.4 (Benchmark, context switch)

---- Score : 848856 ctxswc/S

+--- Score : 839008 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.5 (Benchmark, threads, full cycle)

---- Score : 160345 threads/S

+--- Score : 155165 threads/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.6 (Benchmark, threads, create only)

---- Score : 230238 threads/S

+--- Score : 223798 threads/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.7 (Benchmark, mass reschedule, 5 threads)

---- Score : 62631 reschedules/S, 375786 ctxswc/S

+--- Score : 61138 reschedules/S, 366828 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.8 (Benchmark, round robin context switching)

---- Score : 484540 ctxswc/S

+--- Score : 478120 ctxswc/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.9 (Benchmark, I/O Queues throughput)

---- Score : 491216 bytes/S

+--- Score : 465772 bytes/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.10 (Benchmark, virtual timers set/reset)

---- Score : 647206 timers/S

+--- Score : 647262 timers/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.11 (Benchmark, semaphores wait/signal)

---- Score : 823472 wait+signal/S

+--- Score : 787368 wait+signal/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.12 (Benchmark, mutexes lock/unlock)

---- Score : 601192 lock+unlock/S

+--- Score : 586492 lock+unlock/S

 --- Result: SUCCESS

 ----------------------------------------------------------------------------

 --- Test Case 11.13 (Benchmark, RAM footprint)

---- System: 340 bytes

+--- System: 360 bytes

 --- Thread: 68 bytes

 --- Timer : 20 bytes

 --- Semaph: 12 bytes

diff --git a/docs/src/events.dox b/docs/src/events.dox
index 98ba8d55f..27de187e4 100644
--- a/docs/src/events.dox
+++ b/docs/src/events.dox
@@ -27,33 +27,34 @@
  * explanation.<br>

  * Lets start with the events related terminology:

  * - <b>Event Source</b>, an @p EventSource is a system object that can be

- *   @a broadcasted asynchronously in response of a system event, as example,

- *   when the CAN driver receives a packet from the CAN bus it @a broadcasts

+ *   broadcasted asynchronously in response of a system event, as example,

+ *   when the CAN driver receives a packet from the CAN bus it broadcasts

  *   an event source in order to inform the registered threads that a packet

  *   has just arrived.

  * - <b>Broadcast</b>, the operation performed on an event source in order

- *   to inform the @a registered threads that an event just occurred.

+ *   to inform the registered threads that an event just occurred.

  *   Broadcasting can happened both in interrupt handlers and in threads.

  * - <b>Event Listener</b>, a system object that associates a @p Thread object

  *   to an event source. The process of associating a @p Thread to an

- *   @p EventSource using an @p EventListener is called @a registration.

+ *   @p EventSource using an @p EventListener is called registration.

  * - <b>Registration</b>, action performed by a thread in order to be informed

  *   of events from a specific event source. Of course a thread can be

- *   @a registered on more than one event source by using multiple

- *   @p EventListener objects. Threads can also @a unregister from an event

+ *   registered on more than one event source by using multiple

+ *   @p EventListener objects. Threads can also unregister from an event

  *   source.

- * - <b>Pend</b>, each thread has a mask of @a pending events. The @a broadcast

- *   operation @a pends an event mask on all the @a registered threads.

+ * - <b>Pending Events</b>, event flags waiting to be served by a thread.

+ * - <b>Add</b>, the broadcast operation adds (logical or) an events

+ *   mask to all the registered threads.

  * - <b>Wait</b>, synchronous operation performed by a thread in order to

- *   @a wait a specific combination of events. The API offers a variety of

- *   @a wait functions, please refer to the events API documentation.

+ *   wait a specific combination of events. The API offers a variety of

+ *   wait functions, please refer to the events API documentation.

  * .

  * Note that events are asynchronously generated, as example in an interrupt

  * handler, but are synchronously served.

  *

  * <h2>Events related data structures</h2>

  * The following diagram explains the relationship between an event source,

- * its list of event listeners and the @a registered threads.

+ * its list of event listeners and the registered threads.

  * @dot

   digraph example {

     rankdir="LR";

@@ -97,19 +98,19 @@
     el4 -> t4 [label="el_listener"];

   }

  * @enddot

- * Note that each event listener has a different bit mask to be @a pended on

- * its associated thread when the event source is @a broadcasted, this means

+ * Note that each event listener has a different bit mask to be added on

+ * its associated thread when the event source is broadcasted, this means

  * that each thread can define its own event identifiers independently. A

- * @a broadcast operation can also @a pend more than one bit on the

- * @a registered threads.<br>

- * The threads have a variety of @a wait primitives, they can @a wait for one

- * or more event flags to become @a pending, and can also specify AND/OR

- * conditions, as example a thread can @a wait for any event to become

- * @a pending or @a wait for all the specified events to become @a pending.<br>

+ * broadcast operation can also add more than one bit on the

+ * registered threads.<br>

+ * The threads have a variety of wait primitives, they can wait for one

+ * or more event flags, and can also specify AND/OR conditions, as example

+ * a thread can wait for any of the specified events or wait for all the

+ * specified events.<br>

  * The field @p p_epending is the mask of the currently pending events,

  * the field @p p_ewmask is the mask of the events the thread is interested

  * on in that moment (AND or OR condition depending on the invoked

- * @a wait API).

+ * wait API).

  *

  * <h2>Use Scenarios</h2>

  * Events are best used when one of more of the following conditions are

diff --git a/os/kernel/src/chthreads.c b/os/kernel/src/chthreads.c
index 33ba3741e..5bcadb96d 100644
--- a/os/kernel/src/chthreads.c
+++ b/os/kernel/src/chthreads.c
@@ -67,14 +67,15 @@
  */

 Thread *init_thread(Thread *tp, tprio_t prio) {

 

-  tp->p_flags = THD_MEM_MODE_STATIC;

   tp->p_prio = prio;

   tp->p_state = THD_STATE_SUSPENDED;

-#if CH_USE_REGISTRY

-  REG_INSERT(tp);

+  tp->p_flags = THD_MEM_MODE_STATIC;

+#if CH_USE_MUTEXES

+  tp->p_realprio = prio;

+  tp->p_mtxlist = NULL;

 #endif

-#if CH_USE_DYNAMIC

-  tp->p_refs = 1;

+#if CH_USE_EVENTS

+  tp->p_epending = 0;

 #endif

 #if CH_USE_NESTED_LOCKS

   tp->p_locks = 0;

@@ -82,9 +83,8 @@ Thread *init_thread(Thread *tp, tprio_t prio) {
 #if CH_DBG_THREADS_PROFILING

   tp->p_time = 0;

 #endif

-#if CH_USE_MUTEXES

-  tp->p_realprio = prio;

-  tp->p_mtxlist = NULL;

+#if CH_USE_DYNAMIC

+  tp->p_refs = 1;

 #endif

 #if CH_USE_WAITEXIT

   list_init(&tp->p_waiting);

@@ -92,8 +92,10 @@ Thread *init_thread(Thread *tp, tprio_t prio) {
 #if CH_USE_MESSAGES

   queue_init(&tp->p_msgqueue);

 #endif

-#if CH_USE_EVENTS

-  tp->p_epending = 0;

+#if CH_USE_REGISTRY

+  chSysLock();

+  REG_INSERT(tp);

+  chSysUnlock();

 #endif

 #if defined(THREAD_EXT_EXIT_HOOK)

   THREAD_EXT_INIT_HOOK(tp);

@@ -117,9 +119,6 @@ static void memfill(uint8_t *startp, uint8_t *endp, uint8_t v) {
  *          @p chThdResume().

  * @note    A thread can terminate by calling @p chThdExit() or by simply

  *          returning from its main function.

- * @note    This function can be invoked from within an interrupt handler

- *          even if it is not an I-Class API because it does not touch

- *          any critical kernel data structure.

  *

  * @param[out] wsp      pointer to a working area dedicated to the thread stack

  * @param[in] size      size of the working area

@@ -461,6 +460,8 @@ void chThdRelease(Thread *tp) {
  *          Please read the @ref article_lifecycle article for more details.

  * @pre     The configuration option @p CH_USE_WAITEXIT must be enabled in

  *          order to use this function.

+ * @post    Enabling @p chThdWait() requires 2-4 (depending on the

+ *          architecture) extra bytes in the @p Thread structure.

  * @post    After invoking @p chThdWait() the thread pointer becomes invalid

  *          and must not be used as parameter for further system calls.

  * @note    If @p CH_USE_DYNAMIC is not specified this function just waits for

diff --git a/readme.txt b/readme.txt
index 48036df2f..a21e6b73a 100644
--- a/readme.txt
+++ b/readme.txt
@@ -62,6 +62,8 @@
 *****************************************************************************

 

 *** 2.1.2 ***

+- FIX: Fixed race condition in threads creation (bug 3069854)(backported

+  to 2.0.5).

 - FIX: Fixed broken CH_DBG_ENABLE_STACK_CHECK option in legacy CM3 port (bug

   3064274)(backported to 2.0.5).

 - FIX: Fixed CAN_USE_SLEEP_MODE setting (bug 3064204)(backported to 2.0.5).

@@ -131,7 +133,8 @@
   the name in order to make names more consistent.

       NOTE: ****** Make sure to use a chconf.h file taken from  ******

             ****** this version in your project.                ******

-- CHANGE: Extensive documentation improvements.

+- CHANGE: Extensive documentation improvements, fixed terminology in the

+  events related documentation and articles.

 

 *** 2.1.1 ***

 - FIX: Fixed insufficient stack size for idle thread (bug 3033624)(backported