apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: fcntl based mutex on Solaris/EM64T
Date Mon, 20 Aug 2007 19:56:01 GMT

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 <covener@gmail.com> 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.
>

Also SSLMutex...



Mime
View raw message