Ref: synchronizing init task with an arbitrary number of worker tasks

[Joel Sherrill]

On 09/25/2012 09:22 PM, Andrei Dimitrief-Jianu wrote:
> Yes, I could use a barrier w/ RTEMS_BARRIER_AUTOMATIC_RELEASE.
> However, I would prevent from finishing the tasks that I want to
> synchronize (probably this is the reason why barriers are recommended
> for the initialization phase). I need something that would let the
> workers to finish and keep a count of how many of them have finished,
> and when that count is reached it would release the init task as well.
>
> What I was looking for was a synchronization event that could be
> described by an API similar to:
>
> rtems_status_code rtems_synch_event_initialize( rtems_synch_event
> *synch_event, int wait_count );
>
> rtems_status_code rtems_synch_event_wait_one( rtems_synch_event *synch_event );
>
> rtems_status_code rtems_synch_event_wait_all( rtems_synch_event *synch_event );
>
> rtems_status_code rtems_synch_event_set( rtems_synch_event *synch_event );
>
> rtems_status_code rtems_synch_event_reset( rtems_synch_event *synch_event );
I think you are wanting an event set that is independent of a particular
task. It is an independent object. I have implemented this type of object
for some non-RTEMS customer specific middleware. It is quite complicated
to get the semantics correct.

+ If you allow posting an event to wake up multiple tasks, then it is O(n)
     when you post an event.
+ There is the issue of whether you allow starvation or scan the entire
     blocking set of tasks to see who might be satisfied.
+ When do events get cleared? When the first blocked task is satisfied
     or when all tasks who might be interested in this task are unblocked?

I would be happy to see something like this implemented in RTEMS and
have wanted an event manager that is independent of tasks. But getting
the definition and behaviour correct is not simple.

Another design alternative is to use the classic API event manager
for up to 32 tasks. Assign an event flag (e.g. bit) to each task. The init
task will wait for all tasks to post their event (w/ a timeout I hope). The
application tasks should post their assigned bit when they completed
initialization.  That lets the initialization task know which tasks have
completed initialization within the allotted time.

To hold the application tasks off until all are finished, they should post
their event flag to the Init task. Then block on a manual release barrier.
The application tasks should need to be non-preemptible during 
initialization
to ensure they post their flag and block atomically.

    /* created as non-preemptible, initialization priority */
    rtems_event_send( Init_task_id, my_event_flag );
    rtems_barrier_wait( Init_barrier, forever );
        /* entire application is up, not set our mode/priority to 
"normal" values */
    /* optional */  rtems_task_set_priority( RTEMS_SELF, ... desired 
run-time priority )
    rtems_task_mode( RTEMS_SELF, args for desired preemption mode )

To be completely paranoid, the initialization task could check that the 
count
at the barrier matches the expectations before releasing them. This gives
you the detailed information that the global variables solution does and 
a timeout
capability if all tasks do not complete initialization. If you fail to 
get through
all the application tasks' initialization, then it should be easy to 
report who
failed.

--joel
>
> Regards,
> Andrei.
>
>
> On Tue, Sep 25, 2012 at 7:48 PM, Gedare Bloom<gedare at rtems.org>  wrote:
>> A barrier should work.
>> http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/c_user_225.html#Barrier-Manager
>>
>> On Tue, Sep 25, 2012 at 6:30 PM, Andrei Dimitrief-Jianu
>> <andrei.dimitrief.jianu at gmail.com>  wrote:
>>> Hello,
>>>
>>> I have an arbitrary number of worker tasks created and started in the
>>> init task. I would like to have the init task wait on all of them to
>>> finish and perform an exit() afterwards.
>>>
>>> Anyone can suggest a pattern to use for synchronization?
>>>
>>> Thank you!
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985