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