Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

On 15/06/2020 20:23, Joel Sherrill wrote:




On Mon, Jun 15, 2020 at 11:28 AM 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
>> mailto:sebastian.hu...@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.


I added a ticket for this:

https://devel.rtems.org/ticket/4005

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Gedare Bloom]

On Mon, Jun 15, 2020 at 12:30 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Jun 15, 2020 at 1:01 PM Sebastian Huber 
>  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
>> >>> > >>> > 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Joel Sherrill]

On Mon, Jun 15, 2020 at 1:01 PM Sebastian Huber <
sebastian.hu...@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
> >>>  >>> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Joel Sherrill]

On Mon, Jun 15, 2020 at 11:28 AM Sebastian Huber <
sebastian.hu...@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
> >>  >> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

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


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

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


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

On 15/06/2020 18:13, Joel Sherrill wrote:

On Mon, Jun 15, 2020 at 10:52 AM Sebastian Huber 
> 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?


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Joel Sherrill]

On Mon, Jun 15, 2020 at 10:52 AM Sebastian Huber <
sebastian.hu...@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.

--joel

>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel