Record Locking Help ....

[Ben Duncan]

Bingo !!!! Ok, now that all makes sense. I can that do a maplock
to insure atomicity , set the LOCKBYTE, force the flush, mapunlock
and I am off to the races on record locking.

Roger Oberholtzer wrote:
> 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. 
> 

-- 
Ben Duncan   - VersAccounting Software LLC 336 Elton Road  Jackson MS, 39212
"Never attribute to malice, that which can be adequately explained by stupidity"
        - Hanlon's Razor