[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: The missing membar_X() directive
In article <7C6F6029-5DB3-4C8A-ABFD-5F73E669526B%gmail.com@localhost>,
Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost> wrote:
>I have a route lookup data structure which is fairly speedy and
>which is designed to be modified (i.e. routes added or deleted)
>while lookups are concurrently being done. This is part of a
>project to produce a fully SMP-capable networking stack.
>Unfortunately, however, I wasn't able to eliminate all ordering
>dependencies from the structure; for it to work properly some
>writes to the structure must be seen by readers in the order
>they were written. This in general requires calling membar_producer()
>between the writes that need to be seen in order, and membar_consumer()
>between reads which need to see the same order. While calling
>membar_producer() in the writer isn't a problem, calling membar_consumer()
>in the readers turns out to be a big problem; that's an expensive
>function in the cases I've tried, and that expense is paid in the
>most heavily used, performance-critical lookup functions.
>The thing about the latter functions, however, is that each read
>they do from the structure is dependent on the previous read; what
>it reads tells it how to compute what to read next. This is good,
>since I found this very nice paper
>which has a table and text on page 16 which indicates that the only CPU which
>Linux runs on which may reorder dependent loads is the Alpha. Everything
>else can run without the read barriers.
>So I now have a macro which calls membar_consumer() if compiled for an
>Alpha, but does nothing when compiled for anything else. If there were
>a system membar_X() function which did the right thing for this case, however,
>it wouldn't need the machine-dependent #ifdef.
Would RCU be helpful in your scenario?
Main Index |
Thread Index |