From dev-return-8869-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Dec 31 01:36:44 2002
Return-Path:
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 12014 invoked by uid 500); 31 Dec 2002 01:36:43 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post:
List-Help:
List-Unsubscribe:
List-Subscribe:
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 12003 invoked from network); 31 Dec 2002 01:36:43 -0000
Subject: apr_atomic_t: can we change it to apr_uint32_t?
From: Brian Pane
To: dev@apr.apache.org
Content-Type: text/plain
Organization:
Message-Id: <1041298346.7893.24.camel@desktop>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0
Date: 30 Dec 2002 17:32:26 -0800
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
While trying to replace some mutex-based synchronization
code in the httpd with atomic spinloops, I ran into a
problem in the APR atomic API:
With the API split between apr_uint32_t for the CAS
operation and apr_atomic for most of the get/set
operations, it's impossible to use write portable apps
that need to use both CAS and read/write on the same
object.
I think we could fix this problem by forcing apr_atomic_t
to be defined as apr_uint32_t on all platforms. This would
work fine for the default (mutex-based) atomic implementation,
as well as most platforms for which we currently have custom
code (Linux/x86, Solaris, etc). The only two I'm not sure
of are:
Netware: apr_atomic_t is defined as unsigned long.
Does Netware run on any architectures where an
unsigned long isn't 32 bits?
OS/390: apr_atomic_t is defined as cs_t. Can someone
familiar with that environment please comment on whether
it would be safe to use a uint32 as the atomic type?
Thanks,
Brian