Re: Re: File Locking

This was well written and informative, but I think I still see a bug in this code. After closing the file and opening it for read/write access but before putting the exclusive lock on it, someone else could swoop in and read the file...which would be minus your current entry, as it hasn't been added yet. After adding your entry, the previous persons then add theirs, minus yours. So the file is corrupted. Two alternatives: Append to the file instead of clearing it out OR open it for read/write from the very beginning with exclusive control. Thoughts?

Comment on Re: Re: File Locking

Replies are listed 'Best First'.
Re^3: File Locking by Anonymous Monk on May 07, 2008 at 21:58 UTC
If you're pretty sure the friend is not on the list, then locking the file exclusive for the entire operation is a good idea. However, locking the file in LOCK_EX (instead of LOCK_SH) will limit the concurrency of the operation to 1. So if you just want to check if they are (not) on the list, a shared lock will scale better. Check again after you get an exclusive lock, to avoid race conditions. (For even better scalability, use a database.)	[reply]
Re^4: File Locking by Anonymous Monk on Mar 23, 2011 at 13:15 UTC
OPTIMIST (likely to find the item in the list): Start with a shared lock, and without unlocking, "promote" to an exclusive lock once not found; make sure there is a timer on the attempt to prevent a deadlock, and if the timer goes off then unlock and retry from the top. PESSIMIST (unlikely to find the item in the list): Use the exclusive lock from the beginning.	[reply]
Re^3: File Locking by Anonymous Monk on Apr 24, 2008 at 20:07 UTC
Thank you for your comment!!! I saw this bug also! but wasn't sure if it's a bug. read/write from the very beginning must be a good solution if it works, I haven't tried that out	[reply]