On Mon, Aug 12, 2002 at 03:01:14PM -0400, David Collier-Brown wrote: > Ok, I've been looking at portable locking mechanisms and fcntl. > > A Smarter Colleague (Mark) pointed out that there are > scalability issues with fcntl locks on both Solaris > and Linux, but quite different ones.
We haven't yet hit any scalability problems with fcntl locks on Linux. We use them in Samba a *lot* with the tdb's. Sorry Dave, as far as I can see this (at least the Samba fcntl issue) is a Solaris only problem :-) :-). > Instead, we've been > working with the posix locks, to make them as robust as possible. > In particular, I'm using pthread_mutex_lock() in my code > at work, to do locking on Linux and Solaris, and have been > reasonably happy with it: I'm planning to shift another > program over from realtime semaphores to pthread_mutex_locks > to make avoiding priority inversions easier. > > This would be a better mechnaism to use for the "spinlocks" > case, removing the sparc-only ldstub calls, and the gcc-only > assembler, in favor of a lock that doesn't spin, and does > have good behavior under evil stresses. > In particular, for anyone who supports EOWNERDEAD, we > can put in under #ifdef EOWNERDEAD a call to a guaranteed cleanup > routine, (pthread_mutex_consistent_np) which will recover the state, > after which it can be straightened out, released or recreated. > It also doesn't spin (;-)) > > So: while it's actually in the workaround code, there is > a robust and low-cost lock we can use. > > I'd like to work with someone who groks the spinlock code > to see if we can do this. The tdb spinlock code is really unsafe to use in a production environment due to the potential to lock up the entire db on abend. Now I know you can make no consistency guarentees on abend even with fcntl locks, but when a process abends with an fcntl lock the lock is at least released to allow others to attempt a cleanup. Please just fix the Solaris fcntl lock problem :-) :-). Jeremy.
