Re: barriers vs. reads

[Jens Axboe <axboe@suse.de>]

On Tue, Jun 22 2004, Werner Almesberger wrote:
> I'm working on an elevator with priorities, and I'm wondering what
> semantics are expected from barriers when it comes to reads.
> 
> My problem with read barriers is that they can upset priorities
> quite a bit, by forcing the entire queue to be processed before
> any new (possibly timing-critical) reads are allowed.
> 
> So, is there anything that actually depends on barriers also
> constraining read - or, more likely, read vs. write - order ?
> If not, will there be ?

I don't think a read-barrier currently has a meaning. A write barrier
will force ordering for later reads too, of course.

> Also, it seems, but is never quite explicitly spelt out, that an
> elevator is never really supposed to look for barriers in
> rq->flags, but can solely rely on the insertion position as an
> indication for barriers. Is this true ?

It can't, the insert position doesn't tell you whether it's a barrier or
not. You have to check ->flags for that.

-- 
Jens Axboe