Record Locking Help ....
Roger Oberholtzer
roger
Mon Aug 15 14:10:02 PDT 2005
On Mon, 2005-08-15 at 10:56 -0500, Ben Duncan wrote:
> I thought about semaphores, but the risk of a deadly embrace seems
> to increase with them (just research on their usage seems to indicate that).
>
> I am thinking, at least with the mmap and LOCKBYTE, I have accomplished the same
> thing. The LOCKS will be atomic, any READ with a lock will be done by a this process:
>
> A: Position pointer in file
> B: fcntl lock the LOCKBYTE
> B1: Failed, return failed status
> C: READ record
> C1: test LOCKBYTE
> TRUE: return <record is lock> status
> FALSE:
> Set UID, PID and LOCKBYTE
> Force WRITE immediate of header
> Release fcntl Lock
> D: return DATA
>
> This way I have non-blocking I/O with self advisory locks.
As an aside, with mmap, item C: is not needed. Item A: accomplishes
this. C1: is still needed. But the read() concept goes away.
It is one of the nice things about mmap. I suspect that if you are using
the logic in C1:, item B: would be redundant. And, item B: does slow
down access as it involves the kernel.
--
Roger Oberholtzer <roger at opq.se>
More information about the Linux-users
mailing list