thread concurrent file operation

[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 <moharaka at gmail.com>
>
>> thanks, i think i get it.
>>
>> 2013/1/30 <Valdis.Kletnieks at 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