* Brian Candler <b.cand...@pobox.com> [220705 09:48]:
> 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?
> >
> >
Note also that for referencing a Node to be safe, you must do one of two
things: either use sync/atomic for all reads and writes of Num
(assuming the data in the tree is of a type that can be handled by
sync/atomic), or use sync.RWMutex instead of sync.Mutex, and use RLock
on reads and Lock on writes.
If Node has more than one data field, e.g. {Name string; Age int; ...},
you will have to go with the RWMutex option.
...Marvin
--
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/YsRGy7EdSxvtPoj3%40basil.wdw.
