RE: fcntl file locking and pthreads

From: Mikhail Kruk (meshko@cs.brandeis.edu)
Date: Sun May 04 2003 - 14:29:04 EST


> > CLONE_FILES is an argument to clone(), I'm using pthreads and I don't
> > know if LinuxThreads implementation of pthreads gives me control of
> > how clone is called. Anyway, if I understand what CLONE_FILES does,
> > it should be given to clone, because threads do have to be able
> > to share file
> > descriptors, probably. But not the locks!
>
> What if I have an application where requests are written to files. Thread A
> comes along and notices a job in a file, so it locks the file and reads the
> job. The job will require some network I/O, so the thread goes on to do
> other things. Later on, thread B notices the network I/O has completed, so
> it needs to write to the file, release the lock, and close the file.

I am not persuaded by this example. Why didn't thread A close the file
when it finished the network I/O? That would be logical time to do it. If
it wasn't a file descriptor, but a shared memory region, would you argue
the same about a mutex protecting that memory region?
I think this should not be a question of personal opinions or specific
examples. It should just be consistent. Two reference platforms for
threads are Solaris and Windows. I don't know how Solaris handles this,
but on Windows file locks are per thread, not per process.

[Please cc]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:20 EST