Re: Real tasking problems with Ada.

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert Eachus" <rieachus@comcast.net> wrote in message 
news:914ae4df-cc52-4e6e-b342-584bcac98e88@googlegroups.com...
On Tuesday, August 1, 2017 at 12:45:43 AM UTC-4, Randy Brukardt wrote:

>> Yes, really. Use a discriminant of type CPU, and use that in the aspect.
>> That's an age-old technique, and indeed is the major reason that tasks 
>> have
>> discriminants. You then can allocate the tasks (which would be my
>> suggestion), or you could create the entire set in an aggregate (assuming
>> you have Ada 2020).

>Sorry, you missed what all the shouting was about. ;-)  On the processor I 
>am using
>(an AMD FX-6300 Vishera) running on all CPU cores causes contention for the
>floating-point units.  So for efficiency I have to run on one core from 
>each pair of
>CPU cores.  Currently my program uses 2,4, and 6.  Creating an array 
>indexed by
>CPU doesn't work.

Who said anything about indexing an array by CPUs? If you're able to 
allocate tasks, then create them with whatever CPUs you want and index the 
array by whatever you want, there's no reason that they have to be tied 
together.

Any if you can't, you're probably in a Ravenscar or similar environment, and 
those do not allow any sort of dynamic assignment of CPUs. So you're not 
allowed to do what you want in any case.

...
>Yes, I knew what I was doing was messy and dangerous--or at least required
>careful checking.  My point was that if Maximum_Alignment was large enough,
>I wouldn't be going through the pain.

The maximum alignment an implementation supports comes directly from the 
linker in use. Since most Ada implementations use system linkers that are 
completely out of their control, it's not really possible to support 
anything larger. (One can do it dynamically with a significant waste of 
memory, but that is not the sort of solution that is wanted on an embedded 
system.)

                                        Randy.