Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Joel Sherrill]

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?
>
> 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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200615/0a2cd24d/attachment.html>