I think it should be possible to do something using alarm() to provide
timeouts for lock acquisition, but that wouldn't work well inside a
library.

As I understand it, the issue is that there is no "get a lock, wait in
line if it's not available" call. If such a call did exist, it would
need a timeout value to limit how long it would wait. But the current
call simply returns immediately, either with the lock, or without it. If
you didn't get it, your only choice is to try and get it again. However,
if it does become free, there's nothing keeping someone else from
jumping in and grabbing it before you have the chance to try again. The
current approach tries five times with a 1 second delay in between tries
to get the lock, then gives up. If somebody else (in this case kadmind)
is also busily grabbing the lock, and sitting on it, the odds of you
getting in to get it aren't necessarily that good.

Barring a better lock API, the only other little choice is to try more
times and perhaps wait less in between tries. I suppose you could spin
on it, continuously trying to get the lock for a certain interval, but
that would be a bit inefficient.

Relevant Pages

Re: pthread_mutex_trylock vs. pthread_mutex_lock... collect ownership info and put in timeouts to expose ... likely to own the lock.... question to put in instrumentation that will routinely report ... the current time is less overhead...(comp.programming.threads)

Re: Should COBOL be lockedUP for good?......Windows had demonstrated that if a client... I don't think that 'Timeouts' are sensible. ... why I would want to lock a record for some hours, ...(comp.lang.cobol)

Distributor Lock Timeouts...timeouts to any specific activity or activity levels. ... timeouts I also see a spike in lock requests,...replication latency seems to stay about the same. ... whenever I fire up Replication Monitor the lock timeouts increase ...(microsoft.public.sqlserver.replication)