The github link you provided results in a 404 error. > On Apr 22, 2024, at 1:58 PM, Stephen Illingworth > <stephen.illingwo...@gmail.com> wrote: > > Hello, > > I've created a proof-of-concept for a method of defining critical sections. > Crucially, the scheme allows for static analysis, thereby helping prevent > violations of the critical sections. > > It's a simple concept but I think it's something that can be built upon. > > https://github.com/JetSetIlly/critsec > > I'm posting it here because I think it's an interesting problem and I would > like > to hear expert opinion. The problem is a real one but does this solution have > any > merit? > > - > > The basic mechanism in this project is something I've used in a large rproject > where performance is important. I wanted a way of locking access to data but > without the risk of forgetting to unlock it. Very simple: > > func (crit *Section) Lease(f func() error) error { > crit.lock.Lock() > defer crit.lock.Unlock() > return f() > } > > I've been very happy with that but I thought it would be interesting to come > up > with a method for statically analysing usage of the Lease() function. In other > words, to detect those times when I access critical data outside of a Lease. > > What's needed for this to work is a way of tagging data to say that it should > only be accessed 'inside' a Lease(). > > My idea is this: define critical data by embedding a crit.Section struct in a > new struct type: > > type Section struct { > lock sync.Mutex > } > > > type exampleCritSectioning struct { > crit.Section > a int > b bool > } > > We can then lease the critical section: > > var C exampleCritSectioning > _ = C.Lease(func() error { > a = 100 > return nil > }) > > > > So, critical data is identified with the crit.Section type and critical > sections > by the entry and exit of the Lease function. Static analysis is now relatively > simple: > > 1. Find all instances of types that embed the crit.Section type > 2. Find all accesses to data of those types > 3. Check whether the callgraph to those access include a call to the Lease() > function > > > The proof-of-concept project includes an analysis package as well as the crit > package. A detailed example of an analysis report is given in the README > > > Notes > > I haven't used the analysistest package for testing because I had problems > with > getting it to work with a go.work file. The examples/ package is used in lieue > of that. > > A standalone driver for the analysis is in 'analysis/cmd/critcheck' > > The callgraph is created with the 'x/tools/go/callgraph/vta' package. I > didn't put > much though into this so there might be a better graph method. But VTA > provided > the best results during experimentation > > > Regards > Stephen > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/e2d9f1d9-958a-45df-b402-fe98a213fa67n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/e2d9f1d9-958a-45df-b402-fe98a213fa67n%40googlegroups.com?utm_medium=email&utm_source=footer>.
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CB784B45-7498-4C12-98CC-07CEBCFE9DD0%40ix.netcom.com.
