I apologize for not responding to this earlier.

This is something that I had considered in the past, but avoided for a couple of reasons:

• I had been concerned that there may be use cases in the future in which operations that are currently read-only might require making changes to the data in some form (e.g., maintaining password policy state for bind operations, or perhaps updating other state information for other kinds of read operations).
• The in-memory directory server is primarily meant for some relatively simple use cases, and especially for use in things like unit tests for LDAP-enabled applications, where performance is typically not a substantial concern.

However, I have gone ahead and updated the LDAP SDK to make changes to support concurrency for methods that don't attempt to make any changes to the data. I didn't look at the pull request that you submitted because we don't currently accept third-party contributions (as noted here). These changes will be included in the next release of the LDAP SDK (which will probably be out by the end of June, although there's no hard schedule as yet), but you can test them now by checking out and building the LDAP SDK for yourself.