kenj wrote:
> [...] This commit contains the contentious (in my mind)
> __pmHandleToPtr_unlocked() change ... reviewing this pre-empts the
> discussion about how to fix the context create/destroy race that I
> wanted us to resolve as a first step of restating this effort.
Sure. Let's resolve it!
> I also am unconvinced that any lock inversion existed in the
> original design and implementation
What are you referring to as "original"?
> and would like to understand that (if it exists) before we embark on
> a development path that relies on helgrind to find lock inversions
> rather than design to avoid lock inversions.
It sounds as though you are suspicious that helgrind is unreliable:
that the lock inversion errors are mistaken. Let me assure you that
every case I've studied, it was genuine.
Whether each report represents a design flaw vs. an implementation bug
is a separate question. It's not hard to see intuitively the basic
design level cause of lock ordering bugs: use of the libpcp lock AND
per-context locks (AND some others). There is no standard (and
definitely no formal assertion/checking) as to which type of lock must
or must not be held upon entry to which lower level libpcp functions,
so they often aggressively take locks of whatever type they want.
With libpcp being recursive, they can often get away with this.
... but scale up, race, and boom.
- FChE
|