Re: (ITS#4917) at_insert() moves sat_ad_mutex

[h.b.furuseth@usit.uio.no]

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...

-- 
Regards,
Hallvard