Patch for pthread get and set affinity

[Joel Sherrill]

Gedare..

We discussed this privately when you raised this to me. It should not be part of the scheduler per thread data. lf you do then the data just disappears from the API perspective when the scheduler doesn't support affinity. It will create a new class of odd errors at the API level which no other implementation of this type of API has. From an API perspective, it is the same as the preempt and timeslicing flags.

It is disabled in non-smp configurations, so doesn't impact minimum footprint.

I seriously considered this and decided it was a bad idea. I don't know if I have veto power :) but if I did, I would invoke it here.

We can revisit this when we have a scheduler with affinity. As it stands now, there is absolutely no way to test any of this code if we move the affinity data to the scheduler.

On Mar 5, 2014 7:21 AM, Gedare Bloom <gedare at rtems.org> wrote:
I agree with Sebastian. I raised this issue on the other patch that
modifies the TCB to include the Cpuset_Control affinity field. That
field should be part of the scheduler's per-thread metadata.

On Wed, Mar 5, 2014 at 2:25 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-02-27 14:28, Jennifer Averett wrote:
>>
>> +int pthread_setaffinity_np(
>> +  pthread_t          id,
>> +  size_t             cpusetsize,
>> +  const cpu_set_t   *cpuset)
>> +{
>> +  Objects_Locations        location;
>> +  POSIX_API_Control       *api;
>> +  Thread_Control          *the_thread;
>> +  int                      error;
>> +
>> +  if ( !cpuset )
>> +    return EFAULT;
>> +
>> +  error = _CPU_set_Is_valid( cpuset, cpusetsize );
>> +  if ( error != 0 )
>> +    return EINVAL;
>> +
>> +  the_thread = _Thread_Get( id, &location );
>> +  switch ( location ) {
>> +
>> +    case OBJECTS_LOCAL:
>> +      api = the_thread->API_Extensions[ THREAD_API_POSIX ];
>> +      CPU_COPY( the_thread->affinity.set, cpuset );
>> +      CPU_COPY( api->Attributes.affinityset, cpuset );
>> +      _Objects_Put( &the_thread->Object );
>> +      return 0;
>> +      break;
>> +
>> +#if defined(RTEMS_MULTIPROCESSING)
>> +    case OBJECTS_REMOTE:
>> +#endif
>> +    case OBJECTS_ERROR:
>> +      break;
>> +  }
>> +
>> +  return ESRCH;
>> +}
>
>
> Sorry, for the late answer, but I think this approach makes no sense.
>
> Your pthread_setaffinity_np() implementation just copies some bits from A to
> B.  I think that the thread processor affinity is independent of the API
> (Classic, POSIX, Internal).  So the storage space for the affinity set
> should not be in "api->Attributes".  The scheduler should know about an
> affinity set change, so here we need a scheduler operation invocation.
>
> http://www.rtems.org/wiki/index.php?title=SMP#Scheduler_Implementation
>
> Since the scheduler knows best what do it should also store the affinity set
> in its per-thread control block, e.g. in the stuff allocated via
>
> /**
>  * @brief Scheduler allocate.
>  *
>  * This routine allocates @a the_thread->scheduler
>  */
> RTEMS_INLINE_ROUTINE void* _Scheduler_Allocate(
>   Thread_Control    *the_thread
> )
> {
>   return _Scheduler.Operations.allocate( the_thread );
> }
>
> The scheduler can then use the optimal data structure for its algorithms.
> Since all currently implemented schedulers in RTEMS don't support thread
> affinity this is particularly easy, they only have to check the affinity set
> and need to store nothing.
>
> This makes also _CPU_set_Is_valid() superfluous since the scheduler is then
> responsible to check the affinity set.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140305/dc4a45a0/attachment-0001.html>