On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber <sebastian.hu...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
