Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Gedare Bloom]

On Mon, Jun 15, 2020 at 12:30 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Mon, Jun 15, 2020 at 1:01 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 15/06/2020 18:28, Sebastian Huber wrote:
>>
>> > On 15/06/2020 18:24, Sebastian Huber wrote:
>> >
>> >> On 15/06/2020 18:13, Joel Sherrill wrote:
>> >>
>> >>> On Mon, Jun 15, 2020 at 10:52 AM Sebastian Huber
>> >>> <sebastian.huber at embedded-brains.de
>> >>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>> >>>
>> >>>     Hello,
>> >>>
>> >>>     should the use of RTEMS_GLOBAL be an error in
>> >>>     rtems_semaphore_create(),
>> >>>     rtems_task_create(), rtems_message_queue_create(), and
>> >>>     rtems_partition_create() if RTEMS was configured without
>> >>>     multiprocessing
>> >>>     enabled?
>> >>>
>> >>>
>> >>> Based on the original use cases, I would say no. The idea was that
>> >>> you could create
>> >>> objects and attach to them to limit cohesion. The intention was to
>> >>> avoid the use of
>> >>> global variables for sharing object Ids.  If I offer a service via a
>> >>> message queue
>> >>> globally and my library/service is deployed in a non-MP
>> >>> configuration, it should still
>> >>> work. For tasks, that would imply events. For partitions, it just
>> >>> means the memory is
>> >>> available to "the system" which is a single processor.
>> >>
>> >> Ok, but I think this is a bit inconsistent to the
>> >>
>> >> #if defined(RTEMS_MULTIPROCESSING)
>> >>   if (
>> >>     _Attributes_Is_global( attribute_set )
>> >>       && !_System_state_Is_multiprocessing
>> >>   ) {
>> >>     return RTEMS_MP_NOT_CONFIGURED;
>> >>   }
>> >> #endif
>> >>
>> >> error case. If your system has only one node and is configured for
>> >> multiprocessing shouldn't this behave exactly as an uniprocessor
>> >> system with multiprocessing disabled?
>> >
>> > The background for this question is that I go though the entire
>> > Classic API and write specification items for it. The specification
>> > items include the API documentation:
>> >
>> > https://devel.rtems.org/ticket/3993
>> >
>> > I will probably add some text similar to the one in your e-mail to
>> > explain that the use of RTEMS_GLOBAL is all right in
>> > non-multiprocessing configurations.
>>
>> How should I name this property of an object? Is it the scope of the
>> object (see
>> https://man7.org/linux/man-pages/man3/pthread_attr_setscope.3.html) or
>> the visibility of the object?
>>
I think this usually refers to "Global" scope, which is equivalent to
visibility in this case. Visibility usually is a concept introduced in
OOP, where you can pass around opaque objects (the object is in scope,
but not visible). My $0.02 on that one ...

>> Is "node in a multiprocessing network" a good phrase? I would like to
>> make it a bit easier to separate if from SMP.
>
>
> Although I know that the multiprocessing configuration has been user over
> an MPI network, its main deployment was shared bus computing with
> at least one bank of shared RAM. Think VMEBus CPU cards with a
> dedicated RAM card for shared message processing. Some CPU cards
> did have dual-ported RAM (hence the manager)[1] and  then some RAM
> on a CPU card served the role of the dedicated RAM card.
>
> I never saw one but there are reflective memory cards which could result
> in two card cages seeing the same memory contents.
>
> In that context, any ideas for something better than multiprocessing network
> as a term?
>

I'm reminded of partitioned global address space (PGAS).

> It needs to be in the glossary. I googled shared memory computing but that
> didn't give me what I wanted either.  Gedare needed for academic view.
>
> [1] the dual-ported memory manager was in the original RTEID specification
> and it is certainly the least useful capability defined in it. :)
>
> --joel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel