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-syste... 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@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
-- Regards, Peter Teoh