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

[Delesley Hutchins]

> Actually, it seems annoying to me that lock and unlock are exposing the name
> of the mutex, since it's private, but then it would probably be exposed
> anyway so...

We don't need to expose the name of the mutex.  If you provide a
public getter with LOCK_RETURNED, and always use the getter, then the
mutex is always named through a public method.

In general, I don't like using lock() as the way to name the mutex,
because in most of my real-world use cases, lock() doesn't exist, or
does something other than just locking.  However, I am quite happy to
use a public getter method, and to require users to do so, if people
agree that that's the appropriate solution.

> However, this made me realize there is a small issue with the safety
> analysis as it stands: I cannot see how to express the contracts of lock and
> unlock in the following PIMPL case.

Funny you should bring this up.  I have this exact problem in a number
of real-world cases here at google.  :-) You have to do something like
the following, and it is not always as easy to factor out as this
example would suggest:

class Queue {
public:
  Queue(); Queue(Queue const&); Queue(Queue&&); Queue& operator=(Queue);
  ~Queue();

  const Mutex& getMutex(Impl* i);

  void push(int) EXCLUSIVE_LOCKS_REQUIRED(getMutex(_impl));
  int pop()      EXCLUSIVE_LOCKS_REQUIRED(getMutex(_impl));

  private:
    struct Impl;
    Impl* _impl;
};

// in .cpp file

struct Impl {
  ...
  Mutex mu;
};

const Mutex& Queue::getMutex(Impl* i) LOCK_RETURNED(i->mu) {
  return i->mu;
}

void Queue::push(int) { ... }
int Queue::pop()      { ... }


  -DeLesley

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