Fcntl hangs in 2.2.5 on Solaris

[jra at dp.samba.org]

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.