Re: NetBSD vs Solaris condvar semantics

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Sun, 14 Oct 2012 14:27:48 +0000
   From: Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>

   In the two cases I have come across, dirent locks and range locks, a
   number of condvars, one per dirent or one per range, share a common
   mutex in some common enclosing object, such as a znode.  So, e.g., the
   end of zfs_dirent_unlock looks like

   cv_broadcast(&dl->dl_cv);       /* dl is a dirent lock stored in dzp.  */
   mutex_unlock(&dzp->z_lock);
   cv_destroy(&dl->dl_cv);
   kmem_free(dl, sizeof(*dl));

Of course, this means that putting reference counting into the condvar
implementation isn't enough -- cv_wait actually must not continue to
use the pointer once woken, because of the kmem_free there.  So I am
inclined to say that Solaris is too fast and loose with condvars, and
to adapt the uses of condvars that I find in zfs rather than to tweak
our condvar implementation to support Solaris's (ab)use of it.