hyc@symas.com wrote:

h.b.furuseth@usit.uio.no wrote:

...

If so, the simplest clean fix may be to destroy and reinitialize the mutexes (instead of swapping them back), I think strictly speaking behaviour is undefined if one copies mutexes around at all. Or since one will immediately be destroyed, maybe they should be destroyed when SLAP_AT_DELETED is set, if it is not needed then.

Destroying immediately is not feasible since the attribute may still be in use.

OK.

Show me the POSIX spec that indicates this behavior is undefined.

I wasn't thinking of POSIX in particular (OpenLDAP supports several mutex types afer all), though the pthread_mutex_init() spec says

Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined.

Attempting to initialize an already initialized mutex results in undefined behavior.

The current swap definitely makes it undefined. Whether swapping and copying back does so as well is probably just pedantry when they are unlocked, though in theory I imagine some thread magic could happen even to "passive" mutexes. Except I take it only one thread is running...