lockless file descriptor lookup

[John Baldwin]

On Wednesday 20 May 2009 2:59:52 pm Jeff Roberson wrote:
> On Thu, 14 May 2009, Bruce Evans wrote:
> > Anyway, you probably need atomics that have suitable memory barriers.
> > Memory barriers must affect the compiler and make it perform refreshes
> > for them to work, so you shouldn't need any volatile casts.  E.g., all
> > atomic store operations (including cmpset) have release semantics even
> > if they aren't spelled with "_rel" or implemented using inline asm.
> > On amd64 and i386, they happen to be implemented using inline asm with
> > "memory" clobbers.  The "memory" clobbers force refreshes of all
> > non-local variables.
> 
> So I think I need an _acq memory barrier on the atomic cmpset of the 
> refcount to prevent speculative loading of the fd_ofiles array pointer by 
> the processor and the volatile in the second dereference as I have it 
> now to prevent caching of the pointer by the compiler.  What do you think?
> 
> The references prior to the atomic increment have no real ordering 
> requirements.  Only the ones afterwards need to be strict so that we can 
> verify the results.

I think having the _acq is correct and that the "memory" clobber it contains 
will force the compiler to reload fd_ofiles without needing the volatile cast 
(and thus that you can remove the volatile cast altogether and just add the 
_acq barrier).

-- 
John Baldwin