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

[Delesley Hutchins]

Thanks for the comments!  I know it was a long post.  :-)

> That said, it seems very strange for a method to declare that it
> requires a lock to be held when neither it nor its users can actually
> access that lock.

I tend to agree with you here, which is why I'm suspicious in general
when I see public methods referring to private mutexes.

> That's useless as user documentation because
> it's not actionable — I can't actually modify my code in response to
> your complaints.
>
> You should instead allow the lock expression to more directly state
> what the caller of this method needs to do in order to acquire the lock.

The thread-safety analysis is based on published research in race-free
type systems, and it works by associating every piece of data with its
protecting mutex.  There's no universal way to acquire a particular
mutex -- how the mutex is acquired and released depends entirely on
the interface being provided by the class.  You'd be surprised by how
much variety I've seen in locking schemes.  :-)

The only way to reference lock() instead of the mutex would be to use
some variation of the scheme proposed by David Blakie, but that won't
work in all cases.

> In this case, that means a reference to the lock() method, which is,
> not coincidentally, actually public.

In this case, the lock() method is public.  However in many other
cases, there is no public lock() method.  A pattern I've seen is where
some methods are supposedly "public," but they are are only intended
to be used from a limited context, and the protecting mutex is
available within that context.  The thread safety analysis will
effectively prevent the methods from being called outside of their
intended context.  Similarly, there may be an external helper function
or helper class that is only used from within private methods of a
different class, so it may legitimately need to refer to a private
mutex within that class.

> Going further, in principle, these expressions should really be
> access-checked *from the perspective of a valid user of this method*:
> that is, they should only be access-checked in the context of the class
> when the annotated method is non-public.  For a public method, they
> should really be access-checked from a totally unprivileged context.

I tend to agree with this, but that would be a stricter level of
access control than we currently use, and it is actually stricter than
what C++ normally does with private types.

  -DeLesley

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