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