Patch for pthread get and set affinity

[Gedare Bloom]

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