thread concurrent file operation

thread concurrent file operation

[Karaoui mohamed lamine]

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 

thread concurrent file operation

[Tobias Boege]

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

thread concurrent file operation

[Valdis.Kletnieks at vt.edu]

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 

thread concurrent file operation

[Valdis.Kletnieks at vt.edu]

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 

thread concurrent file operation

[Karaoui mohamed lamine]

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 

thread concurrent file operation

[Valdis.Kletnieks at vt.edu]

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 

thread concurrent file operation

[Jimmy Pan]

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 

thread concurrent file operation

[Peter Teoh]

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 

thread concurrent file operation

[Karaoui mohamed lamine]

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 

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@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 

thread concurrent file operation

[Karaoui mohamed lamine]

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 

thread concurrent file operation

[Peter Teoh]

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