[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/libraries/libldap_r rmutex.c threads.c

Hallvard B Furuseth wrote:
Howard Chu writes:
Hallvard B Furuseth wrote:
Opheader.oh_tid (alias Operation.o_tid) is never set, yet
overlays/accesslog.c uses the value as the owner thread ID.
Hm, I don't know what happened with oh_tid, but I think it would be
better to actually set it, in case others need the thread ID in the
future. On some systems pthread_self() is an expensive call, best to
avoid calling it needlessly, especially since we have only a small
pool of threads; we can get the thread IDs once and never need to ask

Actually, I don't see any code in OpenLDAP which needs the thread ID
from ldap_pvt_thread_self(). What it it needs is _some_ value which is
unique to the thread. In slapd, the operation's thread context will do
nicely for that - including in your rmutex, since the caller passes it
an ID.

Yes, we could just pass the thread context and change the rmutex owner to a void *, that would be fine.

Though when I googled for recursive mutexes, the first seemingly
relevant hit was a long rant from some Posix personality about why
recursive mutexes are a bad idea, "you should fix your data structure

I presume you're talking about this rant http://zaval.org/resources/library/butenhof1.html
His primary point is that big locks kill concurrency. In fact, that is exactly what the accesslog overlay must do - it fully serializes writes in order to insure that they complete in CSN order, and that they can be logged in the same order. In this particular case, we cannot tolerate concurrency, and the recursive mutex is precisely the type of lock needed for the design.

Yes, it's a bottleneck. That's life. In practice, it usually improves write throughput, because it eliminates BDB deadlocks, which avoids a lot of wasted effort and I/O in rollbacks and retries.

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/