On Wednesday, 6 July 2022 at 11:33:29 UTC+1 ren...@ix.netcom.com wrote:
> As I said, make the mutating op simply record the desired op on a queue
> and process the serially on another thread. You are essentially
> implementing transactions.
>
But how do you protect tree *readers* from having
Depends on if you “concurrent” readers or serialized interlaced ones.
It depends on you transaction semantics - eg dirty reads, etc.
It is fairly easy for readers to grab the read lock and the writer thread
(since they were added to a queue) to grab the write lock when it has work to
do.
Li
Well, in my case, only the writing goroutine should be able to have access
to the datastructure (to keep the invariants). So I think a mutex should do
the trick.
Indeed, it looks like transactions or a reimplementation of a UI
thread/event loop.
A concurrent hash=array mapped trie might indeed
Hello, I tried your example and I got
"c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
$WORK\b001\_x002.o: in function `_cgo_d32036b73474_Cfunc_print':
/tmp/go-build/cgo-gcc-prolog:49: undefined referen
Hello gophers,
We have just released go1.19rc1, a release candidate version of Go 1.19.
It is cut from release-branch.go1.19 at the revision tagged go1.19rc1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Re
