Re: [PATCH 2.6] serialization of kernelcapi work

[Armin Schindler]

On Sat, 20 Mar 2004, Andrew Morton wrote:
> Armin Schindler <armin@xxxxxxxxxx> wrote:
> >
> > static atomic_t recv_work_count;
> >
> > static void recv_handler(void *data)
> > {
> > 	if (atomic_inc_and_test(&recv_work_count)) {
> > 		do {
> > 			/* work to do */
> > 		} while (!atomic_add_negative(-1, &recv_work_count));
> > 	}
> > }
> >
> > static int __init kcapi_init(void)
> > {
> > 	atomic_set(&recv_work_count, -1);
> > }
> >
> >
> > A second call to the recv_handler() just results in an additional loop
> > of the first one and the second CPU goes on with its work.
>
> It doesn't need to be a counter - it can simply be a flag.  See how (say)
> queue_work() does it.
>
> However you are limiting things so only a single CPU can run `work to do'
> at any time, same as with a semaphore.

Well, limiting the 'work to do' to one CPU is exactly what I need to do,
the code must not run on another CPU at the same time.

If just a 'flag' is used, it is possible to loose an event, the flag like in
queue_work() prevents from running twice only.
But if the first work is just finished and about to reset the flag, the
check for the flag in the second CPU results to do nothing and a possible
needed work is not done.

The idea of using an atomic counter instead of the semaphore is for
performance reasons. It's better if the second work-to-do just increments
a counter, which the first work handles afterwards, than put this thread to
sleep.

Armin


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/