Re: initialized state of capability objects should be locked

[Marcus Brinkmann]

At Sun, 16 Jan 2005 13:09:47 -0500,
Neal H. Walfield wrote:
> 
> When a capability object is returned to the user (via
> hurd_cap_class_alloc), it is locked.  hurd_cap_class_alloc does the
> lock manually.  When a capability is released, _hurd_cap_obj_dealloc
> is called.  _hurd_cap_obj_dealloc takes a locked capability and
> returns it to the slab after unlocking it.  We should change the
> initialization state so that _hurd_cap_obj_constructor enters locked
> objects into the slab thereby eliding this extra lock/unlock sequence.

I don't think so.  Taking a mutex is, maybe not in our current
implementations, but certainly at the abstract level, something that
is inherently tied to the thread performing the operation.  A locked
mutex would have to be unlocked by the thread taking the lock.  This
disallows sharing a locked mutex object via a pool common to all
threads.

Now, you may be able to argue that our current pthread implementations
don't actually make any distinction (for example, we may not implement
checked mutex's etc).  But even if this is true (I haven't checked), I
don't think this is a sane optimization to make (and for what I think
are pretty obvious reasons).

Thanks,
Marcus