ok. It seems like it was a bit of a misuse of the _Once interface to
directly access its lock mechanism. Does this now make the only use of
_Once_Lock inside of _Once? Maybe, _Once_Lock/Unlock should not be
exposed (change to static in once.c)?
On Sun, May 2, 2021 at 11:00 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
> The allocator mutex is recursive and already used for the task creation
> in rtems_timer_initiate_server(). Just use this mutex instead of the
> once mutex to serialize the initialization. This avoids a dependency on
> condition variables which are not used here.
> ---
> cpukit/rtems/src/timerserver.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/rtems/src/timerserver.c b/cpukit/rtems/src/timerserver.c
> index 3c994933cd..28b77e5635 100644
> --- a/cpukit/rtems/src/timerserver.c
> +++ b/cpukit/rtems/src/timerserver.c
> @@ -24,7 +24,6 @@
> #include <rtems.h>
> #include <rtems/rtems/timerimpl.h>
> #include <rtems/rtems/tasksimpl.h>
> -#include <rtems/score/onceimpl.h>
> #include <rtems/score/todimpl.h>
>
> static Timer_server_Control _Timer_server_Default;
> @@ -225,11 +224,10 @@ rtems_status_code rtems_timer_initiate_server(
> )
> {
> rtems_status_code status;
> - Thread_Life_state thread_life_state;
>
> - thread_life_state = _Once_Lock();
> + _Objects_Allocator_lock();
> status = _Timer_server_Initiate( priority, stack_size, attribute_set );
> - _Once_Unlock( thread_life_state );
> + _Objects_Allocator_unlock();
>
> return status;
> }
> --
> 2.26.2
>
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
