Lines Matching refs:mu
20 *guarded by* the mutex ``mu``, then the analysis will issue a warning whenever
21 a piece of code reads or writes to ``foo`` without first locking ``mu``.
35 Mutex mu;
36 int balance GUARDED_BY(mu);
39 balance += amount; // WARNING! Cannot write balance without locking mu.
42 void withdrawImpl(int amount) REQUIRES(mu) {
43 balance -= amount; // OK. Caller must have locked mu.
48 mu.Lock();
49 withdrawImpl(amount); // OK. We've locked mu.
50 } // WARNING! Failed to unlock mu.
53 mu.Lock();
54 b.withdrawImpl(amount); // WARNING! Calling withdrawImpl() requires locking b.mu.
56 mu.Unlock();
61 ``GUARDED_BY`` attribute declares that a thread must lock ``mu`` before it can
64 the calling thread must lock ``mu`` before calling ``withdrawImpl``.
65 Because the caller is assumed to have locked ``mu``, it is safe to modify
72 locks ``this->mu``, it does not lock ``b.mu``. The analysis understands
76 unlock ``mu``. Every lock must have a corresponding unlock, and the analysis
108 if ``mu`` is a mutex, then calling ``mu.Lock()`` causes the calling thread
109 to acquire the capability to access data that is protected by ``mu``. Similarly,
110 calling ``mu.Unlock()`` releases that capability.
166 Mutex mu;
167 int *p1 GUARDED_BY(mu);
168 int *p2 PT_GUARDED_BY(mu);
169 unique_ptr<int> p3 PT_GUARDED_BY(mu);
230 Mutex mu;
231 MyClass myObject GUARDED_BY(mu);
233 void lockAndInit() ACQUIRE(mu) {
234 mu.Lock();
238 void cleanupAndUnlock() RELEASE(mu) {
240 } // Warning! Need to unlock mu.
246 myObject.doSomething(); // Warning, mu is not locked.
259 Mutex mu;
263 // Hide mu from public interface.
264 void Lock() ACQUIRE() { mu.Lock(); }
265 void Unlock() RELEASE() { mu.Unlock(); }
290 Mutex mu;
291 int a GUARDED_BY(mu);
293 void clear() EXCLUDES(mu) {
294 mu.Lock();
296 mu.Unlock();
300 mu.Lock();
301 clear(); // Warning! Caller cannot hold 'mu'.
302 mu.Unlock();
322 Mutex mu;
323 int a GUARDED_BY(mu);
347 Mutex mu;
348 int a GUARDED_BY(mu);
351 Mutex* getMu() RETURN_CAPABILITY(mu) { return μ }
353 // analysis knows that getMu() == mu
481 Mutex mu;
484 mu.Lock();
487 mu.Unlock();
490 void bar() { // No warning. (Should have EXCLUDES(mu)).
491 mu.Lock();
493 mu.Unlock();
497 bif(); // No warning. (Should have EXCLUDES(mu)).
500 void bif() EXCLUDES(mu);
509 For example, using ``REQUIRES(!mu)`` instead of ``EXCLUDES(mu)`` will produce
515 Mutex mu;
517 void foo() REQUIRES(!mu) { // foo() now requires !mu.
518 mu.Lock();
521 mu.Unlock();
525 mu.Lock(); // WARNING! Missing REQUIRES(!mu).
527 mu.Unlock();
531 bif(); // WARNING! Missing REQUIRES(!mu).
534 void bif() REQUIRES(!mu);
582 void bar(Foo* f) REQUIRES(f->mu); // Error: mu undeclared.
586 Mutex mu;
597 Thread safety attributes follow normal C++ access restrictions, so if ``mu``
598 is a private member of ``c``, then it is an error to write ``c.mu`` in an
609 Mutex mu;
612 // For thread safety analysis only. Does not actually return mu.
613 Mutex* getMu() RETURN_CAPABILITY(mu) { return 0; }
615 void doSomething() REQUIRES(mu);
619 // The analysis thinks that c.getMu() == c.mu
625 requires ``c.mu`` to be locked, which cannot be declared directly because ``mu``
646 if (b) mu.Lock();
647 ... // Warning! Mutex 'mu' is not held on every path through here.
648 if (b) mu.Unlock();
689 Mutex mu;
691 mu.Lock();
692 AutoCleanup<Mutex>(&mu, &Mutex::Unlock);
694 } // Warning, mu is not unlocked.
696 In this case, the destructor of ``Autocleanup`` calls ``mu.Unlock()``, so
714 Mutex* mu;
717 MutexUnlocker(Mutex* m) RELEASE(m) : mu(m) { mu->Unlock(); }
718 ~MutexUnlocker() ACQUIRE(mu) { mu->Lock(); }
726 } // Warning: locks munl.mu
731 doesn't know that munl.mu == mutex. The SCOPED_CAPABILITY attribute handles
873 MutexLocker(Mutex *mu) ACQUIRE(mu) : mut(mu) {
874 mu->Lock();