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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e2d9f1d9-958a-45df-b402-fe98a213fa67n%40googlegroups.com.
