[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100604183550.919cde7d.akpm@linux-foundation.org>
Date: Fri, 4 Jun 2010 18:35:50 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Henrik Rydberg" <rydberg@...omail.se>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
Jiri Kosina <jkosina@...e.cz>,
Mika Kuoppala <mika.kuoppala@...ia.com>,
Benjamin Tissoires <tissoire@...a.fr>,
Rafi Rubin <rafi@...s.upenn.edu>
Subject: Re: [PATCH 1/4] input: Introduce buflock, a one-to-many circular
buffer mechanism
On Thu, 3 Jun 2010 10:00:59 +0200 "Henrik Rydberg" <rydberg@...omail.se> wrote:
> In spite of the many lock patterns and fifo helpers in the kernel, the
> case of a single writer feeding many readers via a circular buffer
> seems to be uncovered. This patch adds the buflock, a minimalistic
> interface implementing SMP-safe locking for such a buffer. Under
> normal operation, given adequate buffer size, the operation is
> lock-less. The template is given the name buflock to emphasize that
> the locking depends on the buffer read/write clashes.
>
Seems that reviewers have already covered most of the oddities.
> +/*
> + * Write to buffer without locking
> + *
> + * bw - the buflock_writer keeping track of the write position
> + * buf - the buffer to write to (array of item type)
> + * size - the size of the circular buffer (must be a power of two)
> + * item - the item to write
> + *
> + * There is no locking involved during write, so this method is
> + * suitable to use in interrupt context.
> + */
And if the buffer fills up, it silently overwrites old data?
There are many options in this sort of thing. Certain choices have
been made here and they should be spelled out exhaustively please.
> +#define buflock_write(bw, buf, size, item) \
> + do { \
> + bw.next_head = (bw.head + 1) & ((size) - 1); \
> + smp_wmb(); \
> + buf[bw.head] = item; \
> + smp_wmb(); \
> + bw.head = bw.next_head; \
> + smp_wmb(); \
> + } while (0)
I don't think there's a reason why these all had to be implemented as
bloaty, un-typesafe macros? Especially as buggy ones which reference
their arguments multiple times!
Code it in C if possible, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists