#247 Use POSIX RW locks instead of NSPR implementation
Closed: wontfix None Opened 10 years ago by rmeggins.

https://bugzilla.redhat.com/show_bug.cgi?id=730387

The NSPR RW lock implementation does not safely allow re-entrant use of reader
locks.  If a writer lock is waiting, all reader locks are blocked.  This
includes threads that already hold a reader lock and are trying to obtain
another reader lock.  This leads to a deadlock.  This issue has been reported
to the NSPR developers, but they are hesitant to fix it.  NSPR does not
currently keep track of the threads that own locks, so there's no way for it to
differentiate a thread asking for it's first reader lock and one who already
holds a reader lock.  The NSPR developers are hesitant to add this as they feel
it would degrade performance.

POSIX RW locks safely allow re-entrant reader locks to be used.  We should use
the POSIX implementation to avoid deadlocks in ns-slapd, as we do have areas
where we use reader locks in a re-entrant fashion.

To switch the RW lock implementation, we need to refactor the 389-ds-base code
to use a new slapi_rwlock_* API anywhere we use RW locks.  We currently call
PR_RWLock_*() functions from many places within the code.  The slapi_rwlock_*
API should be able to switch implementations between NSPR RW locks and POSIX RW
locks based on defines.  We can then add a configure test to use POSIX RW locks
if available, with an override switch to use NSPR locks if that is needed on
certain platforms.

commit changeset:f9b199e/389-ds-base
Author: Nathan Kinder nkinder@redhat.com
Date: Wed Aug 17 09:20:26 2011 -0700
This adds a new slapi_rwlock API and uses it throughout the server.
Internally, this API can allow either NSPR or POSIX rwlocks to be
used for different platforms. This patch makes it use the POSIX
implementation on Linux platforms since the NSPR implementation
does not safely allow re-entrant reader locks to be used.

Added initial screened field value.

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.10

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/247

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata