[Date Prev][Date Next] [Chronological] [Thread] [Top]

[no subject]

        by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id e8CI02j45219
        for <openldap-its-out@OpenLDAP.org>; Tue, 12 Sep 2000 18:00:02 GMT
Date: Tue, 12 Sep 2000 18:00:02 GMT
Message-Id: <200009121800.e8CI02j45219@galois.openldap.org>
From: gaprotosoaie@adexa.com
To: openldap-its@OpenLDAP.org
Subject: Fix for "deadlock for the second and other following requests for Windows NT(2000)" (ITS#732)
X-Loop: openldap-its@OpenLDAP.org

This is a multi-part message in MIME format.

------=_NextPart_000_004D_01C01CC1.BA40F920
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,


One more fix for OpenLDAP for Windows NT/2000.

On 2.0.1 we have
- for NT
    int ldap_pvt_thread_mutex_trylock( ldap_pvt_thread_mutex_t *mp )
    {
     DWORD status;

     status =3D WaitForSingleObject( *mp, 0 );
     if ( (status =3D=3D WAIT_FAILED) || (status =3D=3D WAIT_TIMEOUT) )
      return 0;
     else
      return 1;
    }

- for Solaris

    int ldap_pvt_thread_mutex_trylock( ldap_pvt_thread_mutex_t *mp )
    {
     return( mutex_trylock( mp ) );
    }

>From the Solaris 'mutex' manual:

     A call to pthread_mutex_lock()  or  mutex_lock()  locks  the
     mutex  object  referenced  by  mp.   If the mutex is already
     locked, the calling thread blocks until the mutex is  freed;
     this  will  return with the mutex object referenced by mp in
     the locked state with the calling thread as its  owner.   If
     the  current  owner of a mutex tries to relock the mutex, it
     will result in deadlock.

     pthread_mutex_trylock() and mutex_trylock() is the  same  as
     pthread_mutex_lock()  and mutex_lock(), respectively, except
     that if the mutex object referenced by mp is locked (by  any
     thread,  including  the  current  thread),  the call returns
     immediately with an error.
...
RETURN VALUES
     If successful, all of these functions return  0;  otherwise,
     an error number is returned.

     pthread_mutex_trylock() or mutex_trylock() returns  0  if  a
     lock  on the mutex object referenced by mp is obtained; oth-
     erwise, an error number is returned.


>From this I can see that the result of the =
"ldap_pvt_thread_mutex_trylock"
function is reversed for NT than Solaris.

With the current implementation, the 'connections_mutex' mutex is =
acquired
twice by the same thread (behavior allowed for NT/2000) in
'slpad/connection.c'
'connection_resched (Connection *conn)' but released only once. So the =
next
attempt to acquire the mutex from a different thread will block forever.

The solution is to reverse the result for the NT implementation of
"ldap_pvt_thread_mutex_trylock" (instead of '0' return '1' and instead =
of
'1' return '0'). With this fix, things do work fine...


Regards,
George Aprotosoaie


------=_NextPart_000_004D_01C01CC1.BA40F920
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Hi=20 All,


One more fix for OpenLDAP for Windows NT/2000.

On = 2.0.1=20 we have
- for NT
    int = ldap_pvt_thread_mutex_trylock(=20 ldap_pvt_thread_mutex_t *mp )
   =20 {
     DWORD = status;

    =20 status =3D WaitForSingleObject( *mp, 0 );
     if = ( (status=20 =3D=3D WAIT_FAILED) || (status =3D=3D WAIT_TIMEOUT) = )
     =20 return 0;
     = else
     =20 return 1;
    }

- for = Solaris

   =20 int ldap_pvt_thread_mutex_trylock( ldap_pvt_thread_mutex_t *mp=20 )
    {
     return( = mutex_trylock( mp=20 ) );
    }

>From the Solaris 'mutex'=20 manual:

     A call to = pthread_mutex_lock() =20 or  mutex_lock()  locks  the
    =20 mutex  object  referenced  by  mp.   If = the mutex=20 is already
     locked, the calling thread blocks = until=20 the mutex is  freed;
     this  = will =20 return with the mutex object referenced by mp = in
     the=20 locked state with the calling thread as its  owner.  =20 If
     the  current  owner of a mutex = tries to=20 relock the mutex, it
     will result in=20 deadlock.

     pthread_mutex_trylock() and=20 mutex_trylock() is the  same  as
    =20 pthread_mutex_lock()  and mutex_lock(), respectively,=20 except
     that if the mutex object referenced = by mp is=20 locked (by  any
     thread,  = including =20 the  current  thread),  the call=20 returns
     immediately with an = error.
...
RETURN=20 VALUES
     If successful, all of these functions = return  0;  otherwise,
     an error = number is=20 returned.

     pthread_mutex_trylock() or=20 mutex_trylock() returns  0  if  = a
    =20 lock  on the mutex object referenced by mp is obtained;=20 oth-
     erwise, an error number is=20 returned.


>From this I can see that the result of the=20 "ldap_pvt_thread_mutex_trylock"
function is reversed for NT than=20 Solaris.

With the current implementation, the 'connections_mutex' = mutex=20 is acquired
twice by the same thread (behavior allowed for NT/2000)=20 in
'slpad/connection.c'
'connection_resched (Connection *conn)' = but=20 released only once. So the next
attempt to acquire the mutex from a = different=20 thread will block forever.

The solution is to reverse the result = for the=20 NT implementation of
"ldap_pvt_thread_mutex_trylock" (instead of '0' = return=20 '1' and instead of
'1' return '0'). With this fix, things do work=20 fine...


Regards,
George=20 Aprotosoaie


------=_NextPart_000_004D_01C01CC1.BA40F920--