mechglue registration of gss_buffer_t pointers

[Tom Yu]

>>>>> "nico" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

nico> Scalability and overall performance relative to the wall clock time to
nico> do a per-message operation.  Which I agree should translate to "lock
nico> contention."

Do you have reason to believe that a hash table implementation using
per-object mutexes plus one whole-table mutex will experience
excessive lock contention?  I'm trying to determine if a finer-grained
locking scheme (e.g. per-bucket mutexes) is justified.

Basically I'm considering:

* hash chain node holds the registered pointer value and a mutex
  controlling freeing of that pointer

* whole-table mutex controls access to the table, including lookups,
  linking, and unlinking

* mechglue registers a pointer by doing

  ** acquire lock on whole table
  ** verify that pointer is not already in table
  ** allocate new node
  ** store pointer and specific mech ID
  ** link node
  ** release lock on whole table

* mechglue gss_release_buffer() does

  ** acquire lock on whole table
  ** acquire lock on the node
  ** release lock on whole table
  ** call specific mech's gss_release_buffer()
  ** acquire lock on whole table
  ** unlink node
  ** unlock and free node
  ** release lock on whole table

Whether or not to hold the whole-table lock across the call to the
specific mech's gss_release_buffer() depends on how much risk there is
that a mech will have a slow release_buffer() implementation.

---Tom