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.
http://lwn.net/Articles/263130/ (see the picture here)
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards,
Peter Teoh
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
