r204350 - Replacing the exclusive_lock_function, shared_lock_function and unlock_function attributes with the acquire_capability and release_capability attributes. The old spellings will continue to work, but the underlying semantic attributes have been replaced.

[Delesley Hutchins]

This looks perfect, thanks!  Your work on more flexible attributes
comes in handy here.  :-)   I'll want a C++ test case as well, but I
can add that later.

On Fri, Mar 21, 2014 at 6:15 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> Here is an initial implementation of that feature request -- is this
> what you were thinking of?
>
> ~Aaron
>
> On Thu, Mar 20, 2014 at 6:55 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Thu, Mar 20, 2014 at 6:48 PM, Delesley Hutchins <delesley at google.com> wrote:
>>> The analysis currently has a single unlock_function attribute, which
>>> will unlock both exclusive and shared locks.  There's a feature
>>> request to add shared_unlock_function and exclusive_unlock_function
>>> attributes.  (These should issue a warning if they are used to unlock
>>> the wrong kind of capability.) Any chance you could wrap those up into
>>> the unlock_capability attribute?
>>
>> Right now, we have release_capability, release_shared_capability and
>> release_generic_capability. I think the intention was that
>> release_capability == exclusive_unlock_function,
>> release_shared_capability == shared_unlock_function, and
>> release_generic_capability == unlock_function. If you agree with that
>> mapping, I think it should be possible to implement (I'll run the
>> patch by you before committing though, just to be sure the semantics
>> are what you're looking for).
>>
>> ~Aaron



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