Hi! > > >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)? > > If two threads are changing one filehandle at the same time, then the > program is broken. I can't see how the kernel making updates to 64bit > filehandles "atomic" helps. You could still seek in one thread, then > seek in another and then start the write in the first and get a wrong > result. Changes to a shared filehandle of any kind requires locking to > work reliably, so additional slow downs and locking in the kernel won't > fix anything. Well, app may be broken, or it may be trying to confuse you. If you were stracing app, it seeked at 1GB and at 7GB, then did read(), you'd be certainly very surprised if it did read secret data at 3GB, right? And ptrace monitors do exist. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
