Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 May 2003 12:33:58 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        current@FreeBSD.org
Subject:   Re: 5.1-RELEASE TODO
Message-ID:  <XFMail.20030522123358.jhb@FreeBSD.org>
In-Reply-To: <3ECCECE6.E1D7E8D0@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 22-May-2003 Terry Lambert wrote:
> 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.

We aren't talking about re-doing the work, we're talking about one
CPU trying to walk the list while it's an inconsistent state and
walking off into the weeds through a stale pointer.  I.e, CPU 0
removes an item from the list while CPU 1 is walking over that item.
Duh.

> 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.

Since the locks are only used on shared lists, they aren't present on
lists that don't need protecting, whereas doing them in the queue macros
itself would pessimize all lists, unless you want to have a runtime
check and function call.  Also, one thing you clearly have not noticed
is that locks that cover lists usually also cover several other members of
a related data structure, so you often need the lock anyways while you
manipulate several data members of a structure.

>> > 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@ list though.
> 
> Just because your friend jumped off a cliff...

So what is your magic solution for making rtld thread-safe when
looking up unresolved symbols on first reference?

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030522123358.jhb>