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 <mohar...@gmail.com>wrote: > > Tahnks guys! > > 2013/1/30 Karaoui mohamed lamine <mohar...@gmail.com> > >> thanks, i think i get it. >> >> 2013/1/30 <valdis.kletni...@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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Regards, Peter Teoh
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies