<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 11:28 AM 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: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></blockquote><div><br></div><div>Agreed. With 30 years of hindsight, we should ensure that affinity and</div><div>this setting follow the same behavior rule. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The background for this question is that I go though the entire Classic <br>
API and write specification items for it. The specification items <br>
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 non-multiprocessing <br>
configurations.<br></blockquote><div><br></div><div>+1 </div></div></div>