ConcurrentHashMap works that way in Java. Multiple write locks on portions of
the table and CAS/atomic reading.
> On Feb 13, 2023, at 1:45 PM, 'drc...@google.com' via golang-nuts
> wrote:
>
> Could you use an applicative data structure? (e.g., a balanced binary tree
> where you allocate a n
Could you use an applicative data structure? (e.g., a balanced binary tree
where you allocate a new spine for each insertion/deletion)
That has log N overhead to read, log N storage allocated per write, but I
think if you CAS the writes, the reads can proceed with a lightweight
barrier.
On Sun
On Sun, Feb 5, 2023, 4:34 AM Juliusz Chroboczek 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.
>
> > Thanks for the benchmark. You're right: if
>> 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.
> Thanks for the benchmark. You're right: if you have hundreds of
> goroutines doing nothing but acquiring a re
