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

[John McCall]

On Oct 31, 2012, at 4:38 PM, Delesley Hutchins wrote:
>> 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.  :-)

Sure.

> 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.

Your analysis recognizes arbitrary expressions in these contexts as long
as they resolve to something that works like a lock, right?  Why not also,
as an alternative, permit arbitrary expressions that happen to resolve
to calls to methods with the THREAD_SAFETY_ACQUIRES_LOCK
attribute?  e.g.
  THREAD_SAFETY_REQUIRES_LOCK(lock())
In other words, I am simply proposing that you accept an alternate way
of specifying the lock;  this should not deeply affect your algorithm.

>> 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.

Okay, but you're checking from the context of that method (or at least its
class), so unless the method which relies on the lock being held actually
doesn't have access to the lock, this shouldn't be a problem.

I can imagine situations where that would be true, but only with some
sort of external locking where there probably isn't a static path from the
object to the lock in the first place.  Otherwise, locks are overwhelmingly
likely to be privileged data.

> 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.

Sure, but why not befriend the helper class or function if it's going to
rely on internal details of this other class?

John.