Well, I found something on sun’s website about the fcntl "compatibility"
implementation of flock.
Locking a segment that is already locked by the calling process
causes the old lock type to be removed and the new lock type to
take effect.
So, I guessed that repeated lock calls by a process that already has a
lock will briefly release the lock before reacquiring it (even for the
same lock type), and that this would potentially allow a writer process
to get the lock before the original reader was done with it, because
another reader had tried to access it. Repeated lock calls happen
because of the existence of several threads in the process (that’s why
the problem only happened with thread_count > 1 and process_count > 1).
Since I already had a reader count (to prevent closing too early with
multiple readers), it was simple to use it to prevent multiple readers
from trying to get the lock.
For the curious, the fixed version is at
http://path.berkeley.edu/~vjoel/ruby/solaris-bug-fixed.rb
This was the last major bug with my software, so I will be releasing it
soon…
Joel VanderWerf wrote:
Since I already had a reader count (to prevent closing too early with
multiple readers), it was simple to use it to prevent multiple readers
from trying to get the lock.
Interestingly, this was a case in which a little “premature
optimization” (using a counter to avoid a system call) would have saved
me two weeks of headaches.
Well, I found something on sun’s website about the fcntl “compatibility”
implementation of flock.
Locking a segment that is already locked by the calling process
causes the old lock type to be removed and the new lock type to
take effect.
well now i’m feeling stupid. i did see that in the man page and didn’t think
all the way through it. i guess the conclusion is that flock can only
coordinate amongst processes, and may not be relied upon (exclusively) to
coordiante amonsgt competing threads - some other mechanism must be used.
thats sort of pertinent information for the description of File#flock IMHO
since people tend, because of the ease, to write multi-threaded programs in
ruby more often that in, say, C and File#flock seems a most natural way to do
this.
-a
···
On Wed, 29 Jan 2003, Joel VanderWerf wrote:
So, I guessed that repeated lock calls by a process that already has a
lock will briefly release the lock before reacquiring it (even for the
same lock type), and that this would potentially allow a writer process
to get the lock before the original reader was done with it, because
another reader had tried to access it. Repeated lock calls happen
because of the existence of several threads in the process (that’s why
the problem only happened with thread_count > 1 and process_count > 1).
Since I already had a reader count (to prevent closing too early with
multiple readers), it was simple to use it to prevent multiple readers
from trying to get the lock.
For the curious, the fixed version is at
http://path.berkeley.edu/~vjoel/ruby/solaris-bug-fixed.rb
This was the last major bug with my software, so I will be releasing it
soon…
–
====================================
Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================
Interestingly, this was a case in which a little “premature
optimization” (using a counter to avoid a system call) would have saved
me two weeks of headaches.
Premature optimization is the root of all evil – Donald Knuth
It might have, in this case, yes.