This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: safety question: locks


Hi -

brad.chen wrote:

> Given that the language system automatically inserts locks to
> protect global data, how do we gain confidence that a translated
> script can't deadlock or have other sorts of locking problems? Is it
> enough to assume that the elaborator and translator are bug-free?

Well, not bug free in the global sense, but in that correct locking
code is emitted for those few constructs that need it (copying values
into/out of temporaries).  Similarly, correct code must be emitted to
track contexts, activity limit counts, error conditions, and a few
other states.

> Or does it also depend on the script? 

Clearly, it must not.  This is related to my general concern about
tapsets written in C, outside the view of the translator.  Such code
would have to show compatibility and as much discipline about locking
and such matters as the translator does.

> Can we make the language system simple enough that we can be
> reasonably confident the lock related code is bug free?

That sounds too vague to answer.

One design portion that is open relates to the array iteration
construct: "for (index in array) { ...  }".  Locking the array being
iterated during the execution of the nested block is not satisfactory
(too easy to deadlock).  I suspect the operation will need to be
defined as taking a snapshot of the array indexes (under a short-lived
lock), then traversing that list with the array unlocked.  Martin's
map code will need to support this, unless someone comes up with a
better solution.

- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]