Lock-based thread safety attributes (r201585) were renamed to "capability" attributes so that we would have a more generalized nomenclature with which to implement capability-based analysis passes. Given this more generalized attribute syntax, I am proposing to add a role-based analysis approach using the capabilities attributes, which works in conjunction with the lock-based analysis. This will be an incremental, on-going WIP -- this initial patch is simply introducing the attributes, with subsequent work being done to provide a per-method analysis pass utilizing the attributes. This is a joint venture between CERT and Google to extend the existing thread safety functionality.
Role capabilities provide a way to protect shared functionality via policy. Eg) a role may define a policy that states a method should never be called from something holding a different role. As a simple example, a method holding the GUI role should not call a method holding the database role because the policy says they are mutually exclusive. This patch introduces attributes allowing you to express role management: asserting that a capability is held and acquiring/releasing a capability. There is some skeleton documentation for the attributes included in the patch. ~Aaron
NewCapabilities.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
