:) That's what the asterisked note was for in the original question. I don't think I can do that in the real code because the real code is much more complex. Each node actually triggers a callback that may modify another node. That callback is user-created, not framework created so I have no way of knowing if the lock has already been taken.
And I wouldn't want for library users to have to make that distinction themselves. On Tuesday, July 5, 2022 at 3:48:16 PM UTC+2 Brian Candler wrote: > Have a public Set() that does the lock and then calls a private internal > function, which assumes it's already running under the lock. > https://go.dev/play/p/M1XuC8bxCxL > > On Tuesday, 5 July 2022 at 13:32:26 UTC+1 atd...@gmail.com wrote: > >> Hi, >> >> I have a tree datastructure where mutating some nodes *may *trigger a >> mutation on some other tree nodes. >> >> This tree should be accessible by multiple goroutines but mutated by only >> one at a time. >> >> As such, I wanted to have a global lock on the tree such that mutatiing >> node methods should acquire this lock beforehand. >> >> But it seems to require for the mutex to be reentrant? >> >> I have tried to create a very simplified*** model to illustrate >> https://go.dev/play/p/v37cbYQ1jSY >> >> (***) I know people might want to suggest for the Set method to use a >> lockless variant when iterating over the linked nodes but in the real code, >> it iterates over user created callbacks instead and I don't think I can >> expect callbacks writers to juggle between the two kind of methods to avoid >> deadlocks. >> >> Any suggestion? >> >> -- 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/db0206a8-b113-47ba-9aa5-b3d3680870e2n%40googlegroups.com.
