* thread concurrent file operation
@ 2013-01-29 15:35 Karaoui mohamed lamine
2013-01-29 15:56 ` Tobias Boege
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Karaoui mohamed lamine @ 2013-01-29 15:35 UTC (permalink / raw)
To: kernelnewbies
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130129/82cbbe88/attachment.html
^ permalink raw reply [flat|nested] 12+ messages in thread* thread concurrent file operation 2013-01-29 15:35 thread concurrent file operation Karaoui mohamed lamine @ 2013-01-29 15:56 ` Tobias Boege 2013-01-29 16:55 ` Valdis.Kletnieks at vt.edu 2013-01-29 17:25 ` Karaoui mohamed lamine 2013-01-29 16:53 ` Valdis.Kletnieks at vt.edu ` (2 subsequent siblings) 3 siblings, 2 replies; 12+ messages in thread From: Tobias Boege @ 2013-01-29 15:56 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 15:56 ` Tobias Boege @ 2013-01-29 16:55 ` Valdis.Kletnieks at vt.edu 2013-01-29 17:25 ` Karaoui mohamed lamine 1 sibling, 0 replies; 12+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2013-01-29 16:55 UTC (permalink / raw) To: kernelnewbies 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). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130129/051442f9/attachment.bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 15:56 ` Tobias Boege 2013-01-29 16:55 ` Valdis.Kletnieks at vt.edu @ 2013-01-29 17:25 ` Karaoui mohamed lamine 2013-01-29 21:38 ` Valdis.Kletnieks at vt.edu 1 sibling, 1 reply; 12+ messages in thread From: Karaoui mohamed lamine @ 2013-01-29 17:25 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130129/141d7296/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 17:25 ` Karaoui mohamed lamine @ 2013-01-29 21:38 ` Valdis.Kletnieks at vt.edu 0 siblings, 0 replies; 12+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2013-01-29 21:38 UTC (permalink / raw) To: 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130129/8de184d7/attachment.bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 15:35 thread concurrent file operation Karaoui mohamed lamine 2013-01-29 15:56 ` Tobias Boege @ 2013-01-29 16:53 ` Valdis.Kletnieks at vt.edu [not found] ` <CAEEuMqcZFKPnmhbqyzQQJ4DB+tLN=Pbd5fi2oq4qYOeKG6bU7A@mail.gmail.com> 2013-02-06 22:58 ` Jimmy Pan 2013-02-07 2:41 ` Peter Teoh 3 siblings, 1 reply; 12+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2013-01-29 16:53 UTC (permalink / raw) To: kernelnewbies 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.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130129/a7646f57/attachment-0001.bin ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAEEuMqcZFKPnmhbqyzQQJ4DB+tLN=Pbd5fi2oq4qYOeKG6bU7A@mail.gmail.com>]
[parent not found: <17948.1359482378@turing-police.cc.vt.edu>]
[parent not found: <CAEEuMqfdTHrYcvFNV72qz9mrw+2b=ABno5tcr0fjY4EAaOkZ-w@mail.gmail.com>]
[parent not found: <14179.1359507973@turing-police.cc.vt.edu>]
[parent not found: <CAEEuMqfqgmQr6NA=Akbg9Z48RFNSa5r9bVW7AYH88OEdmJtTwg@mail.gmail.com>]
* thread concurrent file operation [not found] ` <CAEEuMqfqgmQr6NA=Akbg9Z48RFNSa5r9bVW7AYH88OEdmJtTwg@mail.gmail.com> @ 2013-02-07 8:44 ` Karaoui mohamed lamine 2013-02-07 10:23 ` Peter Teoh 0 siblings, 1 reply; 12+ messages in thread From: Karaoui mohamed lamine @ 2013-02-07 8:44 UTC (permalink / raw) To: kernelnewbies Tahnks guys! 2013/1/30 Karaoui mohamed lamine <moharaka@gmail.com> > thanks, i think i get it. > > 2013/1/30 <Valdis.Kletnieks@vt.edu> > > On Tue, 29 Jan 2013 20:16:26 +0100, you said: >> >> > Actually my question is : >> > Does POSIX specifies the fact that we need to use "lockf" to be able >> to do >> > read/write operation in different offset ? Is'n the kernel supposed to >> > ensure this ? >> >> If you have non-overlapping writes, the kernel will eventually sort it out >> for you. If your writes overlap, you'll have to provide your own locking >> via lockf() or similar, and synchronization via other methods. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/a1a9322e/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-02-07 8:44 ` Karaoui mohamed lamine @ 2013-02-07 10:23 ` Peter Teoh 2013-02-07 13:49 ` Karaoui mohamed lamine 2013-02-07 13:49 ` Peter Teoh 0 siblings, 2 replies; 12+ messages in thread From: Peter Teoh @ 2013-02-07 10:23 UTC (permalink / raw) To: kernelnewbies Multiple concurrent write() by different thread is possible, as they all can share the same file descriptor in a single similar process, and this is not allowed. So nevertheless, the problem you posed is not allowed/acceptable by the kernel, so Linus himself fixed it: See here: http://lwn.net/Articles/180387/ And Linus patch: http://lwn.net/Articles/180396/ but my present version (3.2.0) has rcu lock over it (higher performance): INIT_LIST_HEAD(&f->f_u.fu_list); atomic_long_set(&f->f_count, 1); rwlock_init(&f->f_owner.lock); spin_lock_init(&f->f_lock); eventpoll_init_file(f); /* f->f_version: 0 */ On Thu, Feb 7, 2013 at 4:44 PM, Karaoui mohamed lamine <moharaka@gmail.com>wrote: > > Tahnks guys! > > 2013/1/30 Karaoui mohamed lamine <moharaka@gmail.com> > >> thanks, i think i get it. >> >> 2013/1/30 <Valdis.Kletnieks@vt.edu> >> >> On Tue, 29 Jan 2013 20:16:26 +0100, you said: >>> >>> > Actually my question is : >>> > Does POSIX specifies the fact that we need to use "lockf" to be able >>> to do >>> > read/write operation in different offset ? Is'n the kernel supposed to >>> > ensure this ? >>> >>> If you have non-overlapping writes, the kernel will eventually sort it >>> out >>> for you. If your writes overlap, you'll have to provide your own locking >>> via lockf() or similar, and synchronization via other methods. >>> >> >> > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/d7cb9103/attachment-0001.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-02-07 10:23 ` Peter Teoh @ 2013-02-07 13:49 ` Karaoui mohamed lamine 2013-02-07 13:49 ` Peter Teoh 1 sibling, 0 replies; 12+ messages in thread From: Karaoui mohamed lamine @ 2013-02-07 13:49 UTC (permalink / raw) To: kernelnewbies Very nice! 2013/2/7 Peter Teoh <htmldeveloper@gmail.com> > Multiple concurrent write() by different thread is possible, as they all > can share the same file descriptor in a single similar process, and this is > not allowed. So nevertheless, the problem you posed is not > allowed/acceptable by the kernel, so Linus himself fixed it: > > See here: > > http://lwn.net/Articles/180387/ > > And Linus patch: > > http://lwn.net/Articles/180396/ > > but my present version (3.2.0) has rcu lock over it (higher performance): > > INIT_LIST_HEAD(&f->f_u.fu_list); > atomic_long_set(&f->f_count, 1); > rwlock_init(&f->f_owner.lock); > spin_lock_init(&f->f_lock); > eventpoll_init_file(f); > /* f->f_version: 0 */ > > > On Thu, Feb 7, 2013 at 4:44 PM, Karaoui mohamed lamine < > moharaka at gmail.com> wrote: > >> >> Tahnks guys! >> >> 2013/1/30 Karaoui mohamed lamine <moharaka@gmail.com> >> >>> thanks, i think i get it. >>> >>> 2013/1/30 <Valdis.Kletnieks@vt.edu> >>> >>> On Tue, 29 Jan 2013 20:16:26 +0100, you said: >>>> >>>> > Actually my question is : >>>> > Does POSIX specifies the fact that we need to use "lockf" to be able >>>> to do >>>> > read/write operation in different offset ? Is'n the kernel supposed to >>>> > ensure this ? >>>> >>>> If you have non-overlapping writes, the kernel will eventually sort it >>>> out >>>> for you. If your writes overlap, you'll have to provide your own >>>> locking >>>> via lockf() or similar, and synchronization via other methods. >>>> >>> >>> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > > > -- > Regards, > Peter Teoh > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/74440808/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-02-07 10:23 ` Peter Teoh 2013-02-07 13:49 ` Karaoui mohamed lamine @ 2013-02-07 13:49 ` Peter Teoh 1 sibling, 0 replies; 12+ messages in thread From: Peter Teoh @ 2013-02-07 13:49 UTC (permalink / raw) To: kernelnewbies To generalize further u can safely say that all synchronous operation have to be thread-safe, except for some APIs as listed here: http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html linux kernel may guarantee thread-safety - but this only apply to serializing data at the per-syscall level. Ie, every read() will complete, before being intercepted by another read() from another thread. But at the file level u still may get file corruption/file datastructure mangled if u mixed write/read without properly serialization at the userspace level. thus, kernel locking + userspace locking are needed - for different purpose. below discussion is useful (first answer esp): http://stackoverflow.com/questions/5268307/thread-safety-of-read-pread-system-calls in the kernel for each file descriptor, there is only one single offset value to indicate the current file pointer position. so at the userspace level, different read/write combination will affect the file pointer value - which explained also why userspace locking (for logical reasons) are needed. On Thu, Feb 7, 2013 at 6:23 PM, Peter Teoh <htmldeveloper@gmail.com> wrote: > Multiple concurrent write() by different thread is possible, as they all > can share the same file descriptor in a single similar process, and this is > not allowed. So nevertheless, the problem you posed is not > allowed/acceptable by the kernel, so Linus himself fixed it: > > See here: > > http://lwn.net/Articles/180387/ > > And Linus patch: > > http://lwn.net/Articles/180396/ > > but my present version (3.2.0) has rcu lock over it (higher performance): > > INIT_LIST_HEAD(&f->f_u.fu_list); > atomic_long_set(&f->f_count, 1); > rwlock_init(&f->f_owner.lock); > spin_lock_init(&f->f_lock); > eventpoll_init_file(f); > /* f->f_version: 0 */ > > > On Thu, Feb 7, 2013 at 4:44 PM, Karaoui mohamed lamine < > moharaka at gmail.com> wrote: > >> >> Tahnks guys! >> >> 2013/1/30 Karaoui mohamed lamine <moharaka@gmail.com> >> >>> thanks, i think i get it. >>> >>> 2013/1/30 <Valdis.Kletnieks@vt.edu> >>> >>> On Tue, 29 Jan 2013 20:16:26 +0100, you said: >>>> >>>> > Actually my question is : >>>> > Does POSIX specifies the fact that we need to use "lockf" to be able >>>> to do >>>> > read/write operation in different offset ? Is'n the kernel supposed to >>>> > ensure this ? >>>> >>>> If you have non-overlapping writes, the kernel will eventually sort it >>>> out >>>> for you. If your writes overlap, you'll have to provide your own >>>> locking >>>> via lockf() or similar, and synchronization via other methods. >>>> >>> >>> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > > > -- > Regards, > Peter Teoh > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/933276dc/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 15:35 thread concurrent file operation Karaoui mohamed lamine 2013-01-29 15:56 ` Tobias Boege 2013-01-29 16:53 ` Valdis.Kletnieks at vt.edu @ 2013-02-06 22:58 ` Jimmy Pan 2013-02-07 2:41 ` Peter Teoh 3 siblings, 0 replies; 12+ messages in thread From: Jimmy Pan @ 2013-02-06 22:58 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/d9e3410e/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* thread concurrent file operation 2013-01-29 15:35 thread concurrent file operation Karaoui mohamed lamine ` (2 preceding siblings ...) 2013-02-06 22:58 ` Jimmy Pan @ 2013-02-07 2:41 ` Peter Teoh 3 siblings, 0 replies; 12+ messages in thread From: Peter Teoh @ 2013-02-07 2:41 UTC (permalink / raw) To: 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/c4476198/attachment-0001.html ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-02-07 13:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-29 15:35 thread concurrent file operation Karaoui mohamed lamine
2013-01-29 15:56 ` Tobias Boege
2013-01-29 16:55 ` Valdis.Kletnieks at vt.edu
2013-01-29 17:25 ` Karaoui mohamed lamine
2013-01-29 21:38 ` Valdis.Kletnieks at vt.edu
2013-01-29 16:53 ` Valdis.Kletnieks at vt.edu
[not found] ` <CAEEuMqcZFKPnmhbqyzQQJ4DB+tLN=Pbd5fi2oq4qYOeKG6bU7A@mail.gmail.com>
[not found] ` <17948.1359482378@turing-police.cc.vt.edu>
[not found] ` <CAEEuMqfdTHrYcvFNV72qz9mrw+2b=ABno5tcr0fjY4EAaOkZ-w@mail.gmail.com>
[not found] ` <14179.1359507973@turing-police.cc.vt.edu>
[not found] ` <CAEEuMqfqgmQr6NA=Akbg9Z48RFNSa5r9bVW7AYH88OEdmJtTwg@mail.gmail.com>
2013-02-07 8:44 ` Karaoui mohamed lamine
2013-02-07 10:23 ` Peter Teoh
2013-02-07 13:49 ` Karaoui mohamed lamine
2013-02-07 13:49 ` Peter Teoh
2013-02-06 22:58 ` Jimmy Pan
2013-02-07 2:41 ` Peter Teoh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.