On Mon, Jun 15, 2020 at 12:30 PM Joel Sherrill <j...@rtems.org> wrote: > > > > 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 >> >>> <sebastian.hu...@embedded-brains.de >> >>> <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? >> > >> > 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
