On Fri, Feb 29, 2008 at 3:33 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > On Fri, Feb 29, 2008 at 10:18 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > > On Fri, Feb 29, 2008 at 1:34 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > > > Sorry this part really puzzled me.... > > > > > > On Sat, Feb 9, 2008 at 8:10 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > > > > > > In the CPU's ALU. inode->i_size is a 64_bit integer, and access to it is > > > > atomic on 64-bit. On a 32-bit arch though, a 64-bit load will be split in > > > > two 32-bit ones where you can get an incoherent value if you're interrupted > > > > between getting the low and the high 32-bit. > > > > > > > > Rene. > > > > > > > I understood what u are saying, as i_size is loff_t, and loff_t is > > > defined as "long long". But the fact is this, of the thousands of > > > assembly instructions in the kernel, in between any two, it can always > > > be interrupted, so long as u ensure that the interrupt handler ensure > > > that all the registers that it modified has been restored back to its > > > original value upon returning. So I don't quite understand why it > > > cannot be interrupted between the upper and lower half of the 32bit > > > processing. > > > > Interrupts are used for many things. What if a timer interrupt occurs > > Yes, agreed, another tasks can switch in. > > > > and it changes the current task? Then a different task can change the > > Yes, another task switch in, will have a totally different task > context (correct term?) eg, stack register, local variables etc. But > we are talking about local variable all the time, another task will > never touch that local variable. For global - u need spin lock. So > when it is return to the original task, the register value/local > variable are all guaranteed to be as it is originally is. I thought we were talking about inode->i_size here? In this case, inode itself might be a local variable -- but it's a pointer pointing to an object that may be accessed from other tasks. Vegard -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
