in ANY updates/changes, locking is always needed, to prevent multiple parties from updating at the same time. but there is another way: lockless updates. one form done in linux kernel is called RCU:
the logic is whenever someone want to change, just write the changes somewhere, so that reconstruction of the change is possible through reading the changes + existing data. (Oracle database, and indeed any database does that too.). so if multiple CPU want to write to the same place, then u still need per-CPU locks for classic RCU:
But for reader, there is no need to lock: just go ahead and read - if u read AFTER the update has started, then u will be reading the older copy, and the last reader will then kick off the merging of the older copy + newer updates.
but these locking are done at the low level - harddisk is data block level.
For vfs_read() - its purpose is to read...and it does not prevent u from writing!!! yes, everything is left to the user at the userspace level...locking/unlocking. because it is done at the FILE level, and so if u have multiple reads and then someone come in and write....yes, there will be corruption. but that is the logic corruption, not the hardware/datablocks corruption, which the kernel aimed to protect.
On Tue, Jan 29, 2013 at 11:35 PM, Karaoui mohamed lamine
<moharaka@gmail.com> wrote:
Hello,
I was looking at how a syscall read/write was done, and i found this :
....
loff_t pos = file_pos_read(f.file);
ret = vfs_read(f.file, buf, count, &pos);
file_pos_write(f.file, pos);
fdput(f);
...
My questions are :
Where did the locking go? I would have imaginated something like :
....
lock(f);
loff_t pos = file_pos_read(f.file);
ret = vfs_read(f.file, buf, count, &pos);
file_pos_write(f.file, pos);
fdput(f);
unlock(f);
...
If multiple threads try to read/write at the same time, they could read/write at the same offset ?
If my understanding are correct, is this POSIX compliant ?
thanks.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Peter Teoh