Go1.18 has a new Mutex TryLock method. https://pkg.go.dev/sync@go1.18#Mutex.TryLock
Petr On Wednesday, March 16, 2022 at 9:36:50 PM UTC-4 mumbling...@gmail.com wrote: > I'm currently working on a project where I emulate a RISC-V processor for > the purpose of using Go when teaching concepts of operating systems. > I'd like for the emulator to resemble a "real" processor to the point that > a realistic operating system can be implemented with most of the > interesting challenges that this encompasses. > One of these challenges is the management of translation caches across > multiple cores which may sometimes require TLB shootdowns. > > A quick summary of TLB shootdowns: process P has two threads T1 and T2 > that run on cores A and B respectively. > When T1 makes a request to deallocate a page, core A has to ensure that T2 > on core B invalidates some cached translations before it marks the page as > free, lest B (executing T2) might find the translation in cache and write > to a page that T2 no longer should have access to. > > My current approach to this is that instead of using a `sync.Mutex` and > `Lock()`, I have created a custom `UntilLock(f func())` which takes in a > function that should be repeatedly executed until the lock is acquired. > > Current implementation: https://pastecord.com/hofoloxuru.go > > Notice that every mutex where a `Lock`-`Unlock`-pair might wrap an > interrupt, has to use the `UntilLock` as a `Lock` might cause the > goroutine to block and never check interrupts. > The issue is further complicated if one resource R might be locked in > function F and another resource S is locked in function G. > In this case, goroutine A might enter F, successfully acquire R, then > signal goroutine B. > At the same time, B enters G, successfully acquires S, then signals > goroutine A. > We have a deadlock. > This is pretty easily resolved though as we just add the interrupt check > to the loop where F and G wait for the other goroutine to execute their > handlers. > > An idea came to me though... > Life would be much easier if Go had signalling between goroutines. > One could extend the syntax as `h := go f() handler` where `handler` > would have the signature: `func handler(signal int)` > You would then signal it with something like `s := sig h 1` to send a > signal of 1 to the goroutine associated with h. > > Idea for how code would look with signalling: > https://pastecord.com/qunyqejexo.go > > This would completely eliminate the issue I am currently facing and though > I'm no expert in the field, I believe Go's scheduler could make the > implementation require very little effort and the overhead would be > practically non-existent. > This signalling would look a lot like OS signals and is a powerful feature > that isn't too complex in my opinion. > -- 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/40268421-0610-4e25-b0d4-a3954c179a28n%40googlegroups.com.
