lkml.org 
[lkml]   [2008]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: file offset corruption on 32-bit machines?
From
Date
>So if you write multithreaded code and don't understand what locking
>around shared resources is for, then your application might break.

I think I know what locking around shared resources is for, which is why
I'm surprised the kernel doesn't do it.

Is it normal for a kernel resource not to be thread-safe (i.e. you don't
get advertised/sensible results if two threads access it at the same
time)?

>Can you give an example where locking is being used correctly where this
can
>possibly fail?

I could accept (though I haven't thought about it) that there aren't any
real-world applications that do simultaneous reads and writes through the
same file pointer. I might even accept that there can be no useful
application that does. But can you say such an application is incorrect?

--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems



\
 
 \ /
  Last update: 2008-04-11 19:03    [W:1.109 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site