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.hu...@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.hu...@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@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
