A possible solution could be to use a logger thread, which does the actuall logging (writing, rotation,...). The treads which have something to log could put a timestamp and the message to a queue, where the logger picks them up.
- The logger could create the time string and use it until the timestamp changes, it would be the only thread doing this and the lock is no longer needed.
- The access to the queue would have to be mutex locked, but only for a few operations to push/pop an item to the queue, time holding the lock should be minimal and reduce contention for this lock
- The logging would be in the "background", the response time for the normal operations would not be affected by logging tasks (eg rotation)

There are lock free queues - see liblfds and concurrencykit

Per 389-ds-base ticket triage, commented as:

journald might solve this.
See also #47968 - [RFE] Send logs to journald

William has a project to improve the overall logging. Performance is a part of it. Closing this ticket as dup or his project.

On 05/12/2016 04:45 PM, William Brown wrote:

Performance was certainly a significant aspect I was going to look at in my logging code clean up. I also wanted to add buffering for the audit logs, and generally remove lots of duplicate code. So I think we can close as a duplicate.

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

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.