Patch for pthread get and set affinity

[Sebastian Huber]

On 2014-03-05 15:21, Joel Sherrill wrote:
> 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 the responsibility of the scheduler set/get thread affinity operation to 
validate/return the affinity sets.  Storing this stuff in an arbitrary format 
in the Thread_Control structure makes no sense since the thread affinity 
support is entirely scheduler dependent.

>
> 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.
>

You can test the code if you add the scheduler set/get affinity operations. 
The default implementation is trivial.  We have only global schedulers, so 
simply check that the affinity set is the set of all processors in the system. 
  For the get simply return the set of all processors.

-- 
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.