apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin <share-apa...@think42.com>
Subject Re: Patch 1 for apr_atomic.c (Solaris 10)
Date Mon, 30 Oct 2006 07:21:12 GMT
On Sun, Oct 29, 2006 at 11:24:06PM -0700, Justin Erenkrantz wrote:
> On 10/29/06, Colin <share-apache@think42.com> wrote:
> >Unfortunately I don't have access to a Solaris 10 machine, so
> >this patch is untested (I will be able to test all subsequent
> >patches though ;-)
> I have Sol10 machines.  =)

Great, somebody needs to test these ;-)

> >Changes to the Solaris 10 specific functions
> >
> >- Fixed atomic_set_32 by adding an appropriate memory barrier.
> This doesn't make a whole lot of sense.  Just by calling
> apr_atomic_read32(), we get a memory barrier which is only released by
> apr_atomic_set32().  Why does reading an atomic mean that no one else
> can update it ever?  What happens if we call a read() without a set()?
> At what other point would it be unlocked?

Erm, memory barriers aren't things that need to be "acquired" and 
"released"; think of them as synchronisation points. Reasoning about
just one CPU we could say that a memory barrier ensures that all
memory operations that, in the instruction stream, occur before the
barrier, are also actually performed before the barrier, and that no
memory operation that, in the instruction stream, occurs after the
barrier, is performed before the barrier (at least that's the case
for the most general two-way read-write-barrier).

An atomic write operation (to an appropriately sized object) therefore
simply means that a CPU, on the bus, actually performs the write in a
way that other CPUs can/must see it.

Similarly an atomic read does not acquire anything, it just must make
sure that the read operation actually takes place, and takes into 
account any changes to the data that another CPU might have made. 

Does this halfway explain why they are necessary?

On further thought: Perhaps you are mixing up memory barriers and the
"load-locked, store-conditional" pair of memory accesses?

> >- Added missing implementations for atomic_read32, atomic_add32,
> >  atomic_sub32 and atomic_casptr.
> These look fine, AFAICT.
> >- Moved #include <atomic.h> into the Solaris 10 section;
> >  prevents redundant include if generic implementation is used.
> *nod*
> >- Fixed atomic_dec_32 and atomic_inc_32; the old versions were
> >  NOT actually atomic because (a) there was no guarantee that
> >  *mem was not changed between reding the value and performing
> >  the atomic update, and (b) the read itself was not preceeded
> >  by an appropriate memory barrier.
> *nod*  -- justin


View raw message