<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 1:01 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 15/06/2020 18:28, Sebastian Huber wrote:<br>
<br>
> On 15/06/2020 18:24, Sebastian Huber wrote:<br>
><br>
>> On 15/06/2020 18:13, Joel Sherrill wrote:<br>
>><br>
>>> On Mon, Jun 15, 2020 at 10:52 AM Sebastian Huber <br>
>>> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
>>><br>
>>>     Hello,<br>
>>><br>
>>>     should the use of RTEMS_GLOBAL be an error in<br>
>>>     rtems_semaphore_create(),<br>
>>>     rtems_task_create(), rtems_message_queue_create(), and<br>
>>>     rtems_partition_create() if RTEMS was configured without<br>
>>>     multiprocessing<br>
>>>     enabled?<br>
>>><br>
>>><br>
>>> Based on the original use cases, I would say no. The idea was that <br>
>>> you could create<br>
>>> objects and attach to them to limit cohesion. The intention was to <br>
>>> avoid the use of<br>
>>> global variables for sharing object Ids.  If I offer a service via a <br>
>>> message queue<br>
>>> globally and my library/service is deployed in a non-MP <br>
>>> configuration, it should still<br>
>>> work. For tasks, that would imply events. For partitions, it just <br>
>>> means the memory is<br>
>>> available to "the system" which is a single processor.<br>
>><br>
>> Ok, but I think this is a bit inconsistent to the<br>
>><br>
>> #if defined(RTEMS_MULTIPROCESSING)<br>
>>   if (<br>
>>     _Attributes_Is_global( attribute_set )<br>
>>       && !_System_state_Is_multiprocessing<br>
>>   ) {<br>
>>     return RTEMS_MP_NOT_CONFIGURED;<br>
>>   }<br>
>> #endif<br>
>><br>
>> error case. If your system has only one node and is configured for <br>
>> multiprocessing shouldn't this behave exactly as an uniprocessor <br>
>> system with multiprocessing disabled? <br>
><br>
> The background for this question is that I go though the entire <br>
> Classic API and write specification items for it. The specification <br>
> items include the API documentation:<br>
><br>
> <a href="https://devel.rtems.org/ticket/3993" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3993</a><br>
><br>
> I will probably add some text similar to the one in your e-mail to <br>
> explain that the use of RTEMS_GLOBAL is all right in <br>
> non-multiprocessing configurations.<br>
<br>
How should I name this property of an object? Is it the scope of the <br>
object (see <br>
<a href="https://man7.org/linux/man-pages/man3/pthread_attr_setscope.3.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man3/pthread_attr_setscope.3.html</a>) or <br>
the visibility of the object?<br>
<br>
Is "node in a multiprocessing network" a good phrase? I would like to <br>
make it a bit easier to separate if from SMP.<br></blockquote><div><br></div><div>Although I know that the multiprocessing configuration has been user over</div><div>an MPI network, its main deployment was shared bus computing with</div><div>at least one bank of shared RAM. Think VMEBus CPU cards with a </div><div>dedicated RAM card for shared message processing. Some CPU cards</div><div>did have dual-ported RAM (hence the manager)[1] and  then some RAM</div><div>on a CPU card served the role of the dedicated RAM card.</div><div><br></div><div>I never saw one but there are reflective memory cards which could result</div><div>in two card cages seeing the same memory contents.</div><div><br></div><div>In that context, any ideas for something better than multiprocessing network</div><div>as a term?</div><div><br></div><div>It needs to be in the glossary. I googled shared memory computing but that</div><div>didn't give me what I wanted either.  Gedare needed for academic view.</div><div><br></div><div>[1] the dual-ported memory manager was in the original RTEID specification</div><div>and it is certainly the least useful capability defined in it. :)</div><div><br></div><div>--joel</div></div></div>