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.
* Lets start with the events related terminology: * - Event Source, 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. * - Broadcast, 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. * - Event Listener, 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. * - Registration, 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. - * - Pend, each thread has a mask of @a pending events. The @a broadcast - * operation @a pends an event mask on all the @a registered threads. + * - Pending Events, event flags waiting to be served by a thread. + * - Add, the broadcast operation adds (logical or) an events + * mask to all the registered threads. * - Wait, 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. * *

Events related data structures

* 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.
- * 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.
+ * broadcast operation can also add more than one bit on the + * registered threads.
+ * 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.
* 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). * *

Use Scenarios

* 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