Re: (more) concurrency issues in libldap_r?

["Pierangelo Masarati" <ando@sys-net.it>]

> Pierangelo Masarati writes:
>> (...) To try and work it out, I've replaced most of the calls to
>>
>>         ldap_pvt_thread_mutex_lock( &some_mutex );
>>
>> with
>>
>>         while ( ldap_pvt_thread_mutex_trylock( &some_mutex ) )
>>                 ldap_pvt_thread_yield();
>>
>> This seems to cure the problem (up to now)
>
> If ldap_pvt_thread_mutex_lock doesn't yield when it has to wait, that
> sounds like a bug in the threads implementation to me.  So I suggest to
> - test it on some other operating system,

I'm testing on all high performance, multiple CPU hardware I can access...

> - bugreport it when it hopefully turns out to be OS-dependent, and
> - insert that code in ldap_pvt_thread_mutex_lock itself, if possible
>   #ifdeffed on a configure test which detects the problem.

No, I simply didn't finish my considerations before sending the message,
sorry.  Of course, just yielding is not a solution; I need to insert some
deadlock resolution strategy as soon as I detect how it occurs. 
Unfortunately this seems to be deeply connected with the other concurrency
issue I'm seeing, that is dangling LDAPConn's seem to remain around, so
that they get freed twice (and fail the second time, of course).  Any time
I try to reproduce this issue I get the deadlock, and vice-versa, so all
the changes I try appear to affect the other issue more than the issue
they're intended for.

I'll be back on this as soon as I can have another (remote) machine booted
with the right OS.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497