Hi Aaron, First of all, thanks for your comments! I'll address the formatting issues and the crash bug ASAP. Weird that it didn't do this here.
On 2 September 2014 14:56, Aaron Ballman <[email protected]> wrote: > This adds all locks to the analyzer as exclusive locks, but the > previous code would handled shared locks separately. Is that > intentional? So the intent behind this change is that regardless of the number of locks that are picked up by the guard object, it is tracked as always single acquisition of the lock guard object itself. The lock on the guard object will reference all of the actual underlying locks that are performed, that are either locked exclusively or shared. In short, to my knowledge it is irrelevant whether the lock on the guard object is shared or exclusive. The guard object gets locked upon construction and unlocked upon destruction. This is why I just picked exclusive. Now that you mention it, this change will indeed break if there are no underlying locks. The set of locks will be empty and our check against empty() to determine whether we are a scoped guard object or not will be incorrect. You know what? Let me take a look at the existing FactEntry class and see if we can introduce some polymorphism here. Ideally, we should treat "lockable" and "scoped_lockable" objects completely separately. -- Ed Schouten <[email protected]> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
