From mboxrd@z Thu Jan 1 00:00:00 1970
From: htmldeveloper@gmail.com (Peter Teoh)
Date: Thu, 7 Feb 2013 21:49:51 +0800
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
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 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
>>
>>> 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
>
--
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130207/933276dc/attachment.html