[cfe-dev] Discussion: should we enforce access control in C++ attributes?

[Delesley Hutchins]

> It seems that the heart of the problem is that you have a region
> controlled by a mutex, and you're using the name of that mutex as a
> proxy for the name of the region, but access to the region does not
> necessarily imply access to the mutex. I think the right solution is
> to find another (accessible) way to name the region, not to provide
> access to the mutex.

So I show a workaround that does exactly this in my original post,
using the LOCK_RETURNED attribute.  Do you object to that particular
way of doing things?

> If your class only has one such region, it wouldn't seem unreasonable
> to me to use the instance of the class as a proxy for your region name
> in most cases (which I believe the thread safety annotations already
> support).

Yes, you can, and I used to advocate that as the correct solution for
simple cases.  There is one problem, though.  I have a few extensions
that let you quantify over a mutex where the instance object is not
available, in order to get around lexical scoping limitations. Those
extensions don't currently work if the mutex isn't explicitly named,
so I would need yet more fanciness in the mutex expression language.

> we should provide a mechanism for classes to expose a name
> for their lockable regions as part of their public API, and I don't
> think those names should be required to be tied to the names of the
> mutexes

We do this already, using the LOCK_RETURNED attribute.  The real
question in my original post is whether LOCK_RETURNED is an acceptable
workaround.

> Are there reasonable cases where it's reasonable to put a
> LOCKS_REQUIRED annotation on a function which doesn't have access to
> the mutex it requires, and also doesn't have access to a mechanism
> which acquires it? I could imagine such cases arising in templates...

You don't need to go as far as templates.  All you need is an external
helper function, that that does not have access to the lock itself,
but is always called from code which does have access to the lock.
Locking requirements propagate, so the helper function can be
arbitrarily far away from the code that calls it.

  -DeLesley

-- 
DeLesley Hutchins | Software Engineer | delesley at google.com | 505-206-0315