Lines Matching refs:capability
103 read/write the data) unless it has the *capability* to do so.
106 methods to acquire and release the capability. The name of the object serves
107 to identify the capability. The most common example is a mutex. For example,
109 to acquire the capability to access data that is protected by ``mu``. Similarly,
110 calling ``mu.Unlock()`` releases that capability.
112 A thread may hold a capability either *exclusively* or *shared*. An exclusive
113 capability can be held by only one thread at a time, while a shared capability
121 security keys, a thread cannot make copy of a capability, nor can it destroy
122 one. A thread can only release a capability to another thread, or acquire one
130 by calculating an approximation of that set, called the *capability
131 environment*. The capability environment is calculated for every program point,
152 general capability model. The prior names are still in use, and will be
160 member is protected by the given capability. Read operations on the data
165 it points to* is protected by the given capability.
192 capabilities. More than one capability may be specified. The capabilities
222 declaring that the function acquires a capability, but does not release it.
223 The given capability must not be held on entry, and will be held on exit
227 function releases the given capability. The capability must be held on entry
343 that the function returns a reference to the given capability. It is used to
392 class can be used as a capability. The string argument specifies the kind of
393 capability in error messages, e.g. ``"mutex"``. See the ``Container`` example
403 locking, in which a capability is acquired in the constructor, and released in
405 and destructor refer to the capability via different names; see the
423 capability, and returns a boolean value indicating success or failure.
428 Because the analysis doesn't support conditional locking, a capability is
455 already holds the given capability, for example by performing a run-time test
456 and terminating if the capability is not held. Presence of this annotation
457 causes the analysis to assume the capability is held after calls to the
497 ensuring that a capability is held before reading or writing to guarded data,
504 * A function which acquires a capability does not have to exclude it.
505 * A function which calls a function that excludes a capability does not
506 have transitively exclude that capability.
538 attribute, in conjunction with the ``!`` operator, to indicate that a capability
800 THREAD_ANNOTATION_ATTRIBUTE__(capability(x))