Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Joel Sherrill]

On Mon, Jun 15, 2020 at 11:28 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> 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?
>

Agreed. With 30 years of hindsight, we should ensure that affinity and
this setting follow the same behavior rule.

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

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200615/fc9518e3/attachment-0001.html>