From mboxrd@z Thu Jan 1 00:00:00 1970 From: moharaka@gmail.com (Karaoui mohamed lamine) Date: Thu, 7 Feb 2013 14:49:46 +0100 Subject: thread concurrent file operation In-Reply-To: References: <14273.1359478432@turing-police.cc.vt.edu> <17948.1359482378@turing-police.cc.vt.edu> <14179.1359507973@turing-police.cc.vt.edu> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org Very nice! 2013/2/7 Peter Teoh > 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 >> >>> thanks, i think i get it. >>> >>> 2013/1/30 >>> >>> 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