> I think that this is done to be able to have sort of a parallel
> execution inside the schedule() routine ( while a CPU is calculating
> counters, the other could be doing a task selection ). However, if I
> don't remember bad my theory classes, a lock is accessed in a "read"
> mode only if we want to access the contents, not to modify them. The
> semantics are that if a lock is accessed in read mode, and another CPU
> wants to access it in read mode also, it can do it. However, if it's
> wants to access it in write mode and it's already accessed in read
> mode, it should wait until it is released ( and all the other
> combinations of reader-writer apply ). I checked the code and it seems
> that the tasklist_lock is only accessed in write mode when the task is
> created or when it exits ( 'cause we need to modify the table structure
> ). Shouldn't it also be accessed in write mode in schedule() when it's
> updating the task table counters ? I think that by doing a read mode
> lock there's less overhead inside the schedule routine, which is
> desirable, but however it seems not to be completely correct.
In the specific case of the scheduler there may be some further tricks
involved, but commonly rw_locks can be used in a sense that they only
refer to the list structure as such not to any data contained in it. That
is, the locks ensure that the list structure will be coherent on each
read, meaning you can't get a stale pointer. Consider
my_ioctl_setting_entry_to_value(dev, { some_entry, some_value })
that gets called concurrently with two different values for the same entry
on a linked list. You typically don't care which of the values will
succeed to be stored. But you usually care a lot about not dereferencing a
dangling pointer so the readlock is sufficient (and more efficient) even
though you're writing data to the list.
Daniel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/