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.
On Tue, 29 Jan 2013, Karaoui mohamed lamine 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 ?
Look some lines above: struct fd f = fdget(fd); Regards, Tobi
On Tue, 29 Jan 2013 16:56:02 +0100, Tobias Boege said:
Look some lines above:
struct fd f = fdget(fd);
That creates a reference, not a lock. It basically assures that the system doesn't reap and reclaim that fd out from under the code. (In other words, it's managing lifetime, not concurrency).
2013/1/29 Tobias Boege <tobias@gambas-buch.de>
On Tue, 29 Jan 2013, Karaoui mohamed lamine 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 ?
Look some lines above:
struct fd f = fdget(fd);
This function is supposed to return the file reference, does do the locking ? It seems that i can't find the lock instruction( with all those rcu instructions, i am little lost), can you guide me throught ?
Regards, Tobi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 29 Jan 2013 18:25:19 +0100, Karaoui mohamed lamine said:
This function is supposed to return the file reference, does do the locking?
Refcounting only, no locking provided by fdget.
It seems that i can't find the lock instruction( with all those rcu instructions, i am little lost), can you guide me throught ?
Because it isn't there. Concurrent writes can happen - that's why lockf() exists, so that multiple programs that want to scribble on the same file can do their locking.
On Tue, 29 Jan 2013 16:35:13 +0100, Karaoui mohamed lamine said:
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 ?
You might want to ponder why the lockf() syscall exists at all.. :)
actually i dont see why there is a need to ptovide a lock by the kernel. the locking should be at userspace. you can test it by massive write to a file, that would demonstrat the kernel didnt confer a lock sent from my samsung 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
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: http://en.wikipedia.org/wiki/Read-copy-update 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: http://lwn.net/Articles/305782/ 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/2001/features/OLS/pdf/pdf/read-copy.pdf http://lwn.net/Articles/262464/ 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@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
participants (5)
-
Jimmy Pan -
Karaoui mohamed lamine -
Peter Teoh -
Tobias Boege -
Valdis.Kletnieks＠vt.edu