[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Fix for "deadlock for the second and other following requests for Windows NT(2000)" (ITS#732)
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--