Thanks for the replies, Thomas.
On 9/7/05, Thomas Petazzoni <thomas.petazzoni@xxxxxxxx> wrote:
Hi,
First of all: please *do* reply *after* the message. Top-posting sucks
( http://en.wikipedia.org/wiki/Top-posting).
*sorry* about that. :)
Roy Smith wrote:
> I'm mostly concerned about a module which export a read/write proc entity to
> user world, but would be most thankful for a general answer.
A general answer is not really possible, or at least won't help you much.
Here can be one : « All data accessed concurrently by different threads
has to be protected against concurrent accesses ». In kernel space, to
do so, you can use:
- atomic operations ;
- spinlocks ;
- semaphores ;
- ?
> how should I lock the proc from user access ?
You don't need to "lock the proc from user access", you need to protect
the data accessed concurrently by different threads.
here's the deal. I'm acquinted with locking issues in the userland. the problem
that is attacking me lately regards kernel code only: let's say I'm handling
data that can be accessed *ONLY* by one thread of execution, which happens
to be a kernel module. normaly, in userland, i would not have to worry about
locking - no other thread of execution have access to the data, and my code
can be executed ONLY by one processor, no matter what. now let's move
to the kernel dimension. here, the same code is run concurrently on every processor -
we are not talking about a task which resides on a specific runqueue list,
and is attached to a certain processor. so when my kernel module gets to
run, it is not attached to any specific processor, and it might even run
in parallel on two or more processors, so even local variables now seems
to demand locking.
where am I wrong here ?
> and more generally: If i can be invoked concurrently on several processors,
> should I lock every variable from myself, too ?
The concurrent access problem doesn't occur only on multi-processor
systems: it can also occur on uni-processor systems, because of the
preemptive scheduling.
You don't need to lock "every variable" again, you need to protect the
data accessed concurrently by different threads. For example, you don't
need to protect local variables (allocated on the stack), but if you
have a global array, a global linked list or a global integer, you need
to protect it against concurrent accesses.
As you don't seem to know well the problem of synchronization, I suggest
you to read the first chapter of
http://greenteapress.com/semaphores/downey05semaphores.pdf. Of course,
the other chapters are also of interest, but the first one is a
presentation of the mutual exclusion problem, etc.
Sincerly,
Thomas
--
Thomas Petazzoni
thomas.petazzoni@xxxxxxxx
