Did we ever discuss what should be done about this??

On Aug 20, 2007, at 3:42 PM, Ruediger Pluem wrote:



On 08/20/2007 05:46 PM, Jim Jagielski wrote:

On Aug 20, 2007, at 11:23 AM, Jeff Trawick wrote:

On 8/19/07, Eric Covener <[EMAIL PROTECTED]> wrote:
A thread in proc1 will get EDEADLK from fcntl() on the LDAP mutex

     A potential for deadlock occurs if a process  controlling  a
     locked  region is put to sleep by attempting to lock another
     process' locked region. If the system detects that  sleeping
     until  a  locked  region is unlocked would cause a deadlock,
     fcntl() will fail with an EDEADLK error.

sounds like process-wide locks such as fcntl() aren't intended for
this type of use

somewhat-simple testcase attached

./a.out lock1 15 lock2 &
./a.out lock2 3 lock1

first process spits out "lock2: Deadlock situation detected/avoided"

haven't tried on any platforms besides Solaris 10
<testfcntl.c>

Assuming I ran it correctly, no prob with OS X (10.4.10):

% cat la
./a.out lock1 15 lock2 &
./a.out lock2 3 lock1
% sh la
Opening lock1...
Locking lock1...
Sleeping 100 seconds...
Opening lock2...
Locking lock2...
Sleeping 100 seconds...
Sleeping 100 seconds in main...
Opening lock1...
Locking lock1...
Sleeping 100 seconds in main...
Opening lock2...
Locking lock2...
Sleeping 100 seconds...
%

Results for Solaris 8:

Opening lock1...
Locking lock1...
Sleeping 100 seconds...
Opening lock2...
Locking lock2...
Sleeping 100 seconds...
Sleeping 100 seconds in main...
Opening lock1...
Locking lock1...
Sleeping 100 seconds in main...
Opening lock2...
Locking lock2...
lock2: Deadlock situation detected/avoided
Sleeping 100 seconds...

Results for Solaris 9:

Opening lock2...
Locking lock2...
Sleeping 100 seconds...
Opening lock1...
Locking lock1...
Sleeping 100 seconds...
Sleeping 100 seconds in main...
Opening lock1...
Locking lock1...
Sleeping 100 seconds in main...
Opening lock2...
Locking lock2...
lock2: Deadlock situation detected/avoided
Sleeping 100 seconds...

Results for SuSE Linux 10.2 (Linux euler 2.6.18.8-0.5- ruediger-20070715 #1 PREEMPT Sun Jul 15 10:44:38 CEST 2007 i686
athlon i386 GNU/Linux)

Opening lock1...
Locking lock1...
Sleeping 100 seconds...
Opening lock2...
Locking lock2...
Sleeping 100 seconds...
Sleeping 100 seconds in main...
Opening lock1...
Locking lock1...
Sleeping 100 seconds in main...
Opening lock2...
Locking lock2...
lock2: Resource deadlock avoided
Sleeping 100 seconds...

So the same seems to happen on Linux. I came across this issue before on Solaris with 3rd party httpd modules that use the default locking mechanism (which is fcntl on Solaris).
They conflict with the AcceptMutex then if it is also using fcntl.

Regards

RĂ¼diger





Reply via email to