Novell eDirectory Dib Lock - DIB Lock How it works - Part 1

1) I'm not sure what you mean when you ask if dib locking is multi-threaded. This is a bit of a strange question, because the whole purpose of locking is to coordinate the actions of multiple threads. If you only had a single thread, there would be no need for locking. Multiple threads may simultaneously request the dib lock, but only one thread at a time is granted the lock. The thread that is granted the lock is allowed to proceed with its LDAP operation, while other threads requesting the lock will be required to wait in a queue until that thread releases the lock. When a thread releases the lock, the lock is then granted to the next thread in the queue, and that thread can then perform its operation, etc.

Note that only threads performing LDAP UPDATE operations (add, modify, delete, etc.) are required to obtain the dib lock before performing the operation. Threads performing LDAP READ operations (search, etc.) are NOT required to obtain a dib lock before performing the operation.

The net effect of this is that all LDAP update operations are serialized - they are performed sequentially - one at a time. They are never done concurrently, even when there are multiple CPUs. So having multiple CPUs does not make update operations more scalable. However, the same is NOT true of LDAP read operations. Multiple threads performing LDAP read operations may all be executing concurrently, and it is likely that multiple CPUs will help in that scenario.

2) The term "dib lock" refers to the granularity of the lock. A "dib" lock locks the entire dib. There are no "entry" locks or "sub-tree" locks in eDir.