Re: [go-nuts] Upgradable RLock

You can implement your own multiple-reader-single-writer-lock using what Go gives you. For example: https://eli.thegreenplace.net/2019/implementing-reader-writer-locks/ > On Jan 30, 2023, at 4:42 PM, Robert Engels wrote: > > Yes but only for a single reader - any concurrent reader is going to

Re: [go-nuts] recommendations please: go source level debugger for linux

On Thursday, February 2, 2023 at 10:49:40 PM UTC-5 Ian Lance Taylor wrote: Have you tried Delve? https://github.com/go-delve/delve Thanks I will check into it. One point about go and PMD, because the compile time is so fast, using PMD is not nearly as painful as it would be in other languages tha

Re: [go-nuts] Upgradable RLock

That is similar to sync.Map works, but it involves much more complex code. More importantly though, if multiple entries need to be keep in sync that technique doesn’t work - at least not directly/easily. This is a common need with associated caches. Even copy on write isn’t always suitable. Ass

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 3:24 PM Robert Engels wrote: > > That only works if what it is pointing to is cheap to copy. If it is a large > multi-layer structure a RW lock is usually more efficient. No significant copying is required, you just get a pointer to the value. Then you have some way to de

[go-nuts] Trying to load DLL generated with CGO reflectively, stuck on WaitForSingleObject

When I use the library on a simple C program with LoadLibraryA(), it works properly but with the DLL loaded in a virtual memory page happens something different, it gets stuck in WaitForSingleObject after running the exported method. I did all the base relocations and proper IAT refactor, even

[go-nuts] Re: Go+Windows+Audio

Hello, im now facing this same problem, did you managed to solve it? El lunes, 7 de noviembre de 2016 a las 18:16:37 UTC+1, d.sh...@gmail.com escribió: > Hi all. > > I've tried to get access to Windows audio from Go program but failed. That > I did below: > 1. Downloaded and built Portaudio (it

Re: [go-nuts] Upgradable RLock

That only works if what it is pointing to is cheap to copy. If it is a large multi-layer structure a RW lock is usually more efficient. > On Feb 4, 2023, at 5:19 PM, Ian Lance Taylor wrote: > > On Sat, Feb 4, 2023 at 3:11 PM Robert Engels wrote: >> >> I think with server processes - with p

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 3:11 PM Robert Engels wrote: > > I think with server processes - with possibly 100k+ connections - the > contention on a “read mainly” cache is more than you think. This test only > uses 500 readers with little work to simulate the 100k case. Not to get too far into the w

Re: [go-nuts] Upgradable RLock

I think with server processes - with possibly 100k+ connections - the contention on a “read mainly” cache is more than you think. This test only uses 500 readers with little work to simulate the 100k case. > On Feb 4, 2023, at 4:59 PM, Ian Lance Taylor wrote: > > On Sat, Feb 4, 2023 at 8:49

Re: [go-nuts] Upgradable RLock

On Sat, Feb 4, 2023 at 8:49 AM robert engels wrote: > > I took some time to put this to a test. The Go program here > https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the lock - but > a large % of runtime holding the lock. > > (You can’t run it on the Playground because of the leng

Re: [go-nuts] Upgradable RLock

Agreed. Copy-on-write is also very good if the shared structure is small. > On Feb 4, 2023, at 1:00 PM, Kurtis Rader wrote: > >  > FWIW, Using an RCU (https://en.wikipedia.org/wiki/Read-copy-update) algorithm > is often the best choice for caches where reads happen several orders of > magnit

Re: [go-nuts] Upgradable RLock

FWIW, Using an RCU (https://en.wikipedia.org/wiki/Read-copy-update) algorithm is often the best choice for caches where reads happen several orders of magnitude more often than writes. RCU usually avoids the need for any mutex by readers. I was working at Sequent Computer Systems when this was impl

Re: [go-nuts] Upgradable RLock

I took some time to put this to a test. The Go program here https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the lock - but a large % of runtime holding the lock. (You can’t run it on the Playground because of the length of time). You can commen