[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: data structures for use in signal handlers

From: Bruno Haible
Subject: Re: data structures for use in signal handlers
Date: Wed, 10 Feb 2021 02:01:16 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; )

Ben Pfaff wrote:
> On Sun, Feb 7, 2021 at 2:57 PM Bruno Haible <bruno@clisp.org> wrote:
> >     (2) Let the signal handler work only on immutable copies of the data
> >         structure. Whenever the other code manipulates the data structure,
> >         it creates an immutable copy of it, for the signal handler to use.
> >         Use an 'asyncsafe-spin' lock through which the signal handler tells
> >         the other threads to not free that immutable copy while it running.
> >
> >         This is tricky; can it actually be made to work?
> >
> >         Btw, there is an obvious requirement: the technique should use 
> > malloc/
> >         free for memory management, and should not have memory leaks.
> >         Algorithms that assume a garbage collected memory management are not
> >         suitable here.
> This makes me think of read-copy-update aka RCU:
> https://en.wikipedia.org/wiki/Read-copy-update
> https://lwn.net/Articles/262464/
> In RCU, code that updates the data structure takes a lock, creates and
> modifies a copy, and then installs a new pointer to the data structure,
> which is otherwise immutable. Readers always access the data structure
> through a pointer. Whichever pointer they happen to see when they
> read the pointer remains available until they're done with it.
> Using RCU is pretty straightforward once you've done a little of it, but
> it takes some reading to understand all of its concepts. It's probably best
> for me not to try to explain it all, because I'll surely get some parts of it
> wrong.
> Building an RCU implementation isn't necessarily difficult (I have done it,
> but the implementation isn't suitable for gnulib).
> There is a liburcu that is under LGPL v2.1: https://liburcu.org/

Thanks for the pointers, Ben. Yes, RCU is the technique I had in mind.
So: "can it actually be made to work?" -> Yes.

But the implementation of liburcu uses extra signals and a helper thread of
its own (or even a helper thread per CPU). 

I have to rephrase the question: can it be made to work in a straightforward
(not necessarily scalability-optimized) way?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]