andreika-git
/
ChibiOS
mirror of https://github.com/andreika-git/ChibiOS.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
This commit is contained in:
gdisirio 2010-09-18 08:31:12 +00:00
parent 9ffea7e261
commit 6c3bddd257
4 changed files with 54 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/reports/STM32F103-72.txt
View File

@ -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

41
docs/src/events.dox
View File

@ -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

27
os/kernel/src/chthreads.c
View File

@ -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

5
readme.txt
View File

@ -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