if the problem is only with the holding of data, you could keep a ref count
for the data, and delete it only when it zeroes out.
But then the checking for callback existence and calling the callback should
be done atomically.
Kedar.
----- Original Message -----
From: "Frank A. Uepping" <Frank.Uepping@t-online.de>
To: <kernelnewbies@nl.linux.org>
Sent: Tuesday, June 24, 2003 11:37 PM
Subject: callbacks and SMP -- a matter of design
> Imagine we have a service which we can use by registering a callback
function.
> The registered callback is then called whenever the service decides so.
> When we are no more interested in the service we release the callback.
>
> E.g.:
>
> struct X {
> void (*callback)(void *data);
> ...
> };
>
> void register_x(struct X *x, void *data); // data is passed to
x.callback()
> void release_x(struct X* x);
>
> I think we could get in trouble on SMP machines with that.
> It could be that one thread is about to call callback() while
> another thread is about to call release_x().
> If release_x() returns before callback() is finished and
> the subsequent code following release_x() invalidates data
> (e.g. kfree(data)) callback() works on with an invalid data ptr
> -- havoc is the result.
>
> How to make this SMP safe?
> Yes we can use spinlocks to make release_x() wait while callback()
> is in execution. But this has the consequence that callback() must be
> fast/non-blocking (holding a spinlock a longer time is not permitted).
>
> Are there any other solutions?
>
> /FAU
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
