I would review the source code of the Java concurrent package. It has links to the relevant academic research.
> On Jan 8, 2021, at 1:29 PM, Nathan Fisher <nfis...@junctionbox.ca> wrote: > > > I was thinking of potential issues if you rebalance the tree as an example. > > I’m not certain what issues could arise as I’ve never considered a concurrent > data structure that lacks some kind of synchronisation for both read and > writes unless it’s immutable copy-on-write or similar. > > Do you happen to have references available for further research? > >> On Tue, Jan 5, 2021 at 20:15, K. Alex Mills <k.alex.mi...@gmail.com> wrote: >>> On Tue, Jan 5, 2021, 6:59 PM Nathan Fisher <nfis...@junctionbox.ca> wrote: >> >>> Does write only locking provide read correctness? I would’ve thought based >>> on the memory model it could cause issues? >>> >>> https://golang.org/ref/mem#tmp_2 >> >> >> It depends on your notion of "read correctness", specifically when you >> consider each read to have occurred with respect to its concurrent writes. >> Linearizability may be a weaker guarantee than you want, and that's okay. >> >> Linearizability requires that, for each operation, you can pick some point >> between the start and end of an operation when it can be said to have >> "occurred". When you consider all the operations in that order, the results >> you see must be the same as a sequential execution. >> >> In the case I have described, we can pick a linearization point for reads >> just before the last write which they passed on their way down the tree. The >> reads should then see all the writes which happened prior to this point. >> >> This isn't the order the operations enter the root, but linearizability >> doesn't care. It doesn't have an opinion on when overlapping operations >> "occur" with respect to one another. >> >> I don't think using a happens-before relation for the program order seen by >> each goroutine is going to cause a problem with respect to choosing these >> linearization points, but maybe I'm missing something. >> >> Maybe also there is a standardized notion of read correctness that you're >> referring to which I am not aware of. > > -- > 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/CA%2Bc2dWexae8DOR4h4M9hgCFps%3D60F7bjr%3DKGPLS3OuvTL-NN7w%40mail.gmail.com. -- 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/A3F7B8D0-54DF-41C6-9D4D-0BECBBAD6D22%40ix.netcom.com.
