[PATCH 18/45] score: Add Thread_queue_Control::Lock

Gedare Bloom gedare at rtems.org
Sun May 17 11:04:17 UTC 2015


On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Move the complete thread queue enqueue procedure into
> _Thread_queue_Enqueue_critical().  It is possible to use the thread
> queue lock to protect state of the object embedding the thread queue.
> This enables per object fine grained locking in the future.
>
> Delete _Thread_queue_Enter_critical_section().
>
> Update #2273.
> ---

> +  _Thread_queue_Destory( &the_condition_variable->Wait_queue );
Typo, Destory. Find/Replace all.

[...]

>  /**
> - *  @brief Gets a pointer to the "first" thread on the_thread_queue.
> + * @brief Returns the first thread on the thread queue if it exists, otherwise
> + * @c NULL (locked).
> + *
> + * The caller must be the owner of the thread queue lock.
> + *
> + * @param[in] the_thread_queue The thread queue.
>   *
> - *  This function returns a pointer to the "first" thread
> - *  on the_thread_queue.  The "first" thread is selected
> - *  based on the discipline of the_thread_queue.
> + * @retval NULL No thread is present on the thread queue.
> + * @retval first The first thread on the thread queue according to the enqueue
> + * order.
> + */
> +Thread_Control *_Thread_queue_First_locked(
> +  Thread_queue_Control *the_thread_queue
> +);
> +
In other places we call such a function variant _unprotected. In the
doxygen, I don't know what you mean by @c NULL (locked) in the @brief,
or why there are two @brief.



More information about the devel mailing list