[cfe-dev] Thread Safety Analysis: negative capabilities and visibility

[Aaron Ballman]

On Mon, Aug 11, 2014 at 11:06 AM, Delesley Hutchins <delesley at google.com> wrote:
> It doesn't require cross-TU analysis, because we're not inferring
> anything.

Yes, we're not inferring anything, but we're also unable to check
situations that would matter. Eg) extern function declared in a.cpp
with a mismatched annotation defined in b.cpp. But I suppose that's no
different than where we're at without negative capabilities either.

> Instead, we're using explicit attributes.  However, that
> means that the programmer must put an explicit REQUIRES(!mu) on every
> function where mu is visible, so restricting visibility is important.

Agreed.

>
> Easy solutions are:
>
> (*) For class members, we can restrict visiblity to the current class.

Public mutexes are hopefully not something you find in the wild, but a
protected mutex may be more prevalent. Could we diagnose anything in
these cases (on the mutex itself), suggesting to restrict access
through annotated functions?

> (*) For global mutexes, which are declared only in a .cpp file, we can
> restrict visibility to that file.

I wonder how often you'd see extern'ed mutexes in the real world? But
if it's declarated static or is in a nonglobal namespace, this would
certainly work.

> For all other mutexes, we suppress warnings.  However, that leads to
> false negatives, in the case where a mutex's visiblity should
> legitimately cross class or TU boundaries.
>
> My idea for an attribute would be declare, on a per-mutex basis, what
> the visibility of that mutex should be.  E.g. "class-local" (the
> default), "name-space local", "TU-local", "module-local" etc.  Given
> the current lack of a good module structure for C++, though, I'm not
> sure how effective that would be, or whether it might merely
> complicate an already bad situation.

I agree that the effectiveness is questionable (whether we'd get
enough benefit to justify the annotation itself).

~Aaron