On Wed, 29 Jan 2003, Joel VanderWerf wrote: > > 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 > > 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 ====================================