389-ds-base

#49308 libglobs copy on write
Closed: wontfix by spichugi. Opened by firstyear.

Closed: wontfix
Reopen Issue

Issue Description

In the processing of a single search we access libglobs nearly 100 times. For larger searches, we make access this more. Many config items use atomics, other are locked by a rwlock. Some items are not even checked correctly by atomics, some are not locked when they should be.

Rather than making everything safe, we should be looking at copy-on-write. When we go to write to the libglobs config, we copy it and make a new transaction. Existing threads have a guaranteed stable configuration, while new operations are able to use the new config.

THe biggest benefit is that this would nearly completely eliminate our need for locking while reading the config, and remove our usage of the atomic set and read types. This would yield a significant improvement to directory server's parallel performance.

Metadata Update from @firstyear:
- Issue assigned to firstyear

Metadata Update from @firstyear:
- Custom field type adjusted to defect
- Issue set to the milestone: 1.4 backlog

My understanding is that you want to change access to config parameters from atomic/rwlock to copy-on-write. Am I correct ?

Sorry in advance for this dummy question. Does it require specific coding style/instructions to use copy-on-write ?

From the consumer perspective there is no change. You just call "config_get_*" as normal.

The main changes will be:

  • At the start of an operation we open a "read" transaction to the libglobs. This makes config_get_* work by accessing the read only structure.
  • When the operation is complete, we close the txn (and it may be freed)
  • When we are in a write, (say dse.c) we open a new write transaction. This copies the whole frontendconfig struct and it's config.
  • writes are then applied to this struct
  • When we finish the writes, we can verify the struct as a whole, then commit just updates a pointer.

Benefit is:

  • Existing operations keep using their config that they had at the start. IE, config values persist for a whole operation
  • New operations would see the "new" written struct
  • There are far less locks involved so it would be faster.
  • There are far less atomics involved, so reads to int values would be faster.

Hope that helps,

Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field version adjusted to None

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/2367

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
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.