[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