You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2007/09/14 20:50:39 UTC
Re: fcntl based mutex on Solaris/EM64T
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 <co...@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.
>
> Regards
>
> Rüdiger
>
>
>
>
Re: fcntl based mutex on Solaris/EM64T
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Apr 15, 2008 at 07:01:26AM -0400, Eric Covener wrote:
> On Fri, Sep 14, 2007 at 2:50 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> >> *snip* can't use two independent fcntl locks on Linux, Solaris, ??
> > Did we ever discuss what should be done about this??
>
> Report on users@httpd reminds me to try to resurrect this. I don't
> see the discussion here but I vaguely recalls someone mentioning it
> would not be acceptable to change APR to choose a different default
> mutex (proc_pthread?) when available. This would still allow a
> program to explicitly choose fcntl mutexes and get itself in trouble
> just like the native calls.
The default was changed to fcntl because of the potential for deadlocks
in use of cross-process pthread mutexes:
http://marc.info/?l=apr-dev&m=108720968023158&w=2
are those issues not seen any more? Since that decision was due to a
potential OS bug (robust mutexes which aren't robust) has it been
confirmed with Sun that this fcntl/EDEADLK is definitely not an OS bug?
Regards,
joe
Re: fcntl based mutex on Solaris/EM64T
Posted by Eric Covener <co...@gmail.com>.
On Fri, Sep 14, 2007 at 2:50 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> *snip* can't use two independent fcntl locks on Linux, Solaris, ??
> Did we ever discuss what should be done about this??
Report on users@httpd reminds me to try to resurrect this. I don't
see the discussion here but I vaguely recalls someone mentioning it
would not be acceptable to change APR to choose a different default
mutex (proc_pthread?) when available. This would still allow a
program to explicitly choose fcntl mutexes and get itself in trouble
just like the native calls.
--
Eric Covener
covener@gmail.com