Re: 5.1-RELEASE TODO

John Baldwin wrote:
> > That's an order of operations problem, not a locking problem.  Just
> > like a lot of the simple queue.h structures that are unnecessarily
> > being locked around modificiations because the macros aren't being
> > rewritten to make the updates atomic.
> 
> Unless you plan to use expensive atomic operations and memory barriers
> to ensure in-order operation pessimizing all the lists that don't need
> protecting you are going to need to protect shared lists.  Please do
> remember that writes from one CPU are not guaranteed to be visible to
> other CPU's in program order.

You don't care if another CPU re-does the work, so long as it
re-does it atomically.  That makes it thread safe without the
introduction of locks.

Introducing locks introduces "expensive atomic operations and memory
barriers"; redoing it introduces an extra function call of overhead
that doesn't matter and is less expensive.


> > It's a really bad idea to imply a locking policy in something as
> > fundamental as the runtime linker code, unless you expect to be
> > able to replace the primitives at compile/link/runtime at some
> > point.
> 
> Unless I'm mistaken we aren't the first set of folks to add locking
> to the runtime linker.  I'm sure that there is already a suitable
> bikeshed over this on the threads_at_ list though.

Just because your friend jumped off a cliff...

-- Terry