Scheduler questions

[Zoltan Menyhart]

I'd like to understand which task structure elements are protected by
which locks (as far as scheduling is concerned). Is there somewhere a
paper summarizing the mutual exclusion rules ?

Let's take some code e.g. from the 2.6.5 kernel:

set_cpus_allowed(task_t *p, cpumask_t new_mask):

	rq = task_rq_lock(p, &flags)
	__set_cpus_allowed(p, new_mask, &req):

		p->cpus_allowed = new_mask
		/*
		 * If the task is not on a runqueue (and not running), then
		 * it is sufficient to simply update the task's cpu field.
		 */
		if (!p->array && !task_running(rq, p))
			set_task_cpu(p, any_online_cpu(p->cpus_allowed))
		/* ... */

	task_rq_unlock(rq, &flags)

Apparently, the "p->cpus_allowed" and the "p->thread_info->cpu" fields
are protected by the "(&per_cpu(runqueues, (p->thread_info->cpu)))->lock".

Which are the other task structure elements protected by the same lock ?

Let's take an example:

- I've got a sleeping task that ran on the CPU #3 previously
- I want to set its CPU mask equal to {1, 2}
- I take the lock of the run queue #3
- I do set the CPU mask of the task
- It's not running (BTW when can happen that "p->array" is NULL and the
  task is still running ?)
- I do set the task's CPU e.g. equal to 2. As a consequence, the task
  falls out of the protection provided by the lock of the run queue #3.
- Someone else deciding to play with the same task, s/he takes the
  lock of the run queue #2 !!!
- Me, I have not arrived yet to the unlock. There are stuffs to do before.
- Both of us think to have the exclusive access right to the task...

Can someone explain me, please, why I have to take a run queue lock
to protect a not running task, and why we do not use "proc_lock"
instead ?

Thanks,

Zoltán Menyhárt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/