Barrier Manager cross-node behaviour

Fri Jan 28 13:39:40 UTC 2022

On Fri, Jan 28, 2022, 7:15 AM Jerzy J <yuralogplus at gmail.com> wrote:

> Hi Joel,
>
> Thank you for your help and clarification, this is exactly what i needed!
>
> In terms of submitting this to the community, the situation is exactly as
> mentioned by Andrew.
>

Thanks for the info Andrew. My long term concern with the qualification
work, particularly the process of modifying rtems-central and generating
content for RTEMS.git, needs to be made familiar to the community.

We need to make sure that the software engineering or users guide covers
all of this.  It may even be a good idea to have some video presentations
that are recorded and put on YouTube.

The formal verification material is even harder but basically the same
process. There should be community instructions for taking formal
verification and modifying and or checking it.

In both cases, that doesn't make skills required to actually update it any
easier but the process should be well documented and easily repeatable with
a known set of tools. And those tools should be acquirable reliably.

>
> >If that statement and any others like it were deleted,
> >would this issue go away?
>
> I think if it's consistent and either doesn't mention nodes at all or does
> so on all of the directives it would definitely be more clear!
>

Overnight, I realized that I should probably grep for the word node in the
users guide and ensure it is only used in the right sections. No point in
relying on eithe one of us to read that he entire thing. ;)

>
> >Please point out all the places where the barrier documentation
> >uses language from a distributed multiprocessing and shouldn't.
>
> As far as I'm aware, I've only seen nodes mentioned in Classic API Guide,
> in Barrier Manager Directives section:
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-create
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-ident
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-delete
>

I'll fix at least that.

Thanks

--joel

>
> Hope that helps and all the best,
> Jerzy
>
> pt., 28 sty 2022 o 12:00 Andrew.Butterfield at scss.tcd.ie <
> Andrew.Butterfield at scss.tcd.ie> napisał(a):
>
>> Hi Joel,
>>   Jerzy is doing a Dissertation on this topic, and we have every plan to
>> feed this back into the community. The is an academic spin-off from the ESA
>> sponsored activity that ran for the last two years or so.
>>
>> I know that the precise way we integrate this stuff back into the
>> community needs to be figured out, and discussion is underway about aspects
>> of this on the devel mailing list.
>>
>> Sebastian and I hope to come to you all with a proposal regarding the
>> Formal Methods part - I'll let him lead that as he has a better feel for
>> what would fit best with community guidelines.
>>
>> Regards,
>>   Andrew
>>
>> --------------------------------------------------------------------
>> Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
>> Lero at TCD, Head of Software Foundations & Verification Research Group
>> School of Computer Science and Statistics,
>> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>>                          http://www.scss.tcd.ie/Andrew.Butterfield/
>> --------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: users <users-bounces at rtems.org> on behalf of Joel Sherrill <
>> joel at rtems.org>
>> Reply to: "joel at rtems.org" <joel at rtems.org>
>> Date: Thursday 27 January 2022 at 23:39
>> To: Jerzy J <yuralogplus at gmail.com>
>> Cc: "rtems-users at rtems.org" <users at rtems.org>
>> Subject: Re: Barrier Manager cross-node behaviour
>>
>>     On Thu, Jan 27, 2022 at 5:04 PM Jerzy J <yuralogplus at gmail.com>
>> wrote:
>>     >
>>     > Hi,
>>     >
>>     > I'm using RTEMS 6 and I'm trying to model the Barrier Manager
>> behaviour
>>     > using Promela.
>>
>>     Cool! Have you modeled anything else? Is this something which could be
>>     submitted to the community and used openly?
>>
>>     Just thinking anything that grows formal verification for RTEMS
>> hopefully
>>     helps if there is the potential for more input. Not that I am likely
>> the one to
>>     build the formal model.
>>
>>     > However, there's one unclear thing to me which I couldn't find an
>> exact
>>     > explanation of in the documentation.
>>     >
>>     > While the `rtems_barrier_ident` directive can only search on the
>> local
>>     > node, if a task already had an id of the barrier from a different
>> node,
>>     > would it be able to call the `rtems_barrier_wait` directive on that
>>     > barrier, or would it get INVALID_ID return code?
>>     > In other words, can a task from one node, call directives on a
>> barrier from
>>     > another node if it had an id of the barrier?
>>
>>     The concept of node only applies when RTEMS is built for
>>     distributed multiprocessing. This is completely different from
>>     the SMP support.
>>
>>     For distributed multiprocessing, the system model is multiple
>>     CPUs cards on a shared bus like VMEbus with an area
>>     of shared memory. In a distributed multiprocessing configuration,
>>     each node is a complete RTEMS executable with an assigned
>>     node number in the system.
>>
>>     For SMP, the cores are tightly integrated, share a memory
>>     image, etc. This is considered one "node".
>>
>>     There is no mixing of models.
>>
>>     With the distributed multiprocessing, a subset of Classic API
>>     services allow an object instance to be created with global
>> visibility.
>>     If global, then the ident service can be used to look up the id
>>     for a name. For example, a task can be global. If created on
>>     node 1, a task on node 2 can change its priority.
>>
>>     I doubt you really care about the distributed multiprocessing
>>     configuration but even if you did, barriers are local only and
>>     can't be accessed by other nodes in a distributed
>>     processing configuration.
>>
>>     > I would also assume that behaviour would be consistent for `delete`
>> and
>>     > `release` directives as well? Although it is mentioned in the
>> `delete`
>>     > directive constraints that only local tasks can delete a barrier,
>> in other
>>     > directives it is not listed as a constraint.
>>
>>     That is probably just an artifact of copying the starting point for
>>     the documentation from another API class that did support
>>     being global.
>>
>>     If that statement and any others like it were deleted,
>>     would this issue go away?
>>
>>     Please point out all the places where the barrier documentation
>>     uses language from a distributed multiprocessing and shouldn't.
>>
>>     Thanks.
>>
>>     --joel
>>
>>     > Thanks you in advance and all the best,
>>     > Jerzy
>>     > _______________________________________________
>>     > users mailing list
>>     > users at rtems.org
>>     > http://lists.rtems.org/mailman/listinfo/users
>>     _______________________________________________
>>     users mailing list
>>     users at rtems.org
>>     http://lists.rtems.org/mailman/listinfo/users
>>
>>