can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code?

[John Baldwin]

On Friday, February 14, 2014 9:30:38 pm Andrey Chernov wrote:
> On 15.02.2014 4:11, John-Mark Gurney wrote:
> >>> This is code example from cpuminer port, in case you are interested, it is very simple:
> >>>
> >>> static inline void affine_to_cpu(int id, int cpu)
> >>> {
> >>>         cpuset_t set;
> >>>         CPU_ZERO(&set);
> >>>         CPU_SET(cpu, &set);
> >>>         cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_CPUSET, -1, sizeof(cpuset_t), &set);
> >>
> >> I think that CPU_WHICH_TID should have been used here.
> > 
> > I agree...  cpuset(2):
> >      The which argument determines how the value of id is interpreted and is
> >      of type cpuwhich_t.  The which argument may have the following values:
> > 
> >            CPU_WHICH_TID       id is lwpid_t (thread id)
> >            CPU_WHICH_PID       id is pid_t (process id)
> >            CPU_WHICH_CPUSET    id is a cpusetid_t (cpuset id)
> >            CPU_WHICH_IRQ       id is an irq number
> > 
> >      An id of '-1' may be used with a which of CPU_WHICH_TID, CPU_WHICH_PID,
> >      or CPU_WHICH_CPUSET to mean the current thread, process, or current
> >      thread's cpuset.  All cpuset syscalls allow this usage.
> 
> The question still remains: why SCHED_ULE and SCHED_4BSD do different
> things here on CPU_WHICH_CPUSET == -1 (current thread's cpuset)? It
> looks like SCHED_ULE changes per/process mask while SCHED_4BSD change
> per/thread mask in that case.

Eh, no.  CPU_WHICH_CPUSET changes the global set that the thread belongs to.  
t is not per proceses or per thread.  Unless you are explicitly creating
new global sets, your thread belongs to the default set (set 1), and this
call is changing the default set (set 1) to only use a single CPU.  This
affects all processes in the machine that do not have their own sets.

-- 
John Baldwin