[PATCH] Updated atomic API

[Brian Pane <br...@cnet.com>]

Thanks to all who provided feedback on the apr_atomic API
changes that I posted last week.  Here's the updated patch
that I'm planning to commit; I'll wait a few days in case
more people want to comment.

Things that have changed since the original patch:
  - Added a new function apr_atomic_xchg32 to exchange
    two values
  - Documented that the atomic functions will implement
    a memory barrier internally

Changes not yet made:
  - Removal of the old API (I saw two comments in favor
    of this, including my own; I'll wait for an official
    3 +1s and no -1s before I start deleting stuff)
  - Return values for the add, subtract, and inc functions
    (I haven't figured out a way to implement these
    efficiently)

Brian

RE: [PATCH] Updated atomic API

["William A. Rowe, Jr." <wr...@apache.org>]

At 03:38 PM 9/19/2003, William A. Rowe, Jr. wrote:
>At 01:32 AM 9/19/2003, Mladen Turk wrote:
>
>>I have a patch (send It back in April) that enable to use the atomic
>>from C++ on WIN32.
>>The problem is the fact that C++ distinguishes unsigned int and LONG
>>mixage as an error.

Never mind my earlier comments - this change is a noop so I've committed
as you proposed.

There is a better way to determine that we are consistently signed or unsigned 
moving forwards :-)  More later...

Bill

RE: [PATCH] Updated atomic API

["William A. Rowe, Jr." <wr...@apache.org>]

At 01:32 AM 9/19/2003, Mladen Turk wrote:

>I have a patch (send It back in April) that enable to use the atomic
>from C++ on WIN32.
>The problem is the fact that C++ distinguishes unsigned int and LONG
>mixage as an error.

That's our bug, then.  Not redeclaring, but we need to make this consistent.

>Unlike the other platforms for WIN32 the apr_atomic_t is 'typedefed' so
>later in the header it is reverted from LONG to apr_uint32_t, so the
>IntelockedXX functions gets apr_uint32_t as a param, and C++ reports
>that as an error.
>
>The patch simply #defines the apr_atomic_t as LONG.

I don't like this solution - please don't commit.  I will propose a better one 
that accommodates both typesafety concerns and the declarations.

If we agree apr_uint32_t is the desired implementation - then we need to do
some very clever casting to fool even C++.  It can be done, al la dynamic
callback function prototypes.  I'll post the patch this evening.

Bill

RE: [PATCH] Updated atomic API

[Mladen Turk <mt...@apache.org>]

> -----Original Message-----
> From: Mladen Turk
> 
> > -----Original Message-----
> > From: Brian Pane
> > 
> > Changes not yet made:
> >   - Removal of the old API (I saw two comments in favor
> >     of this, including my own; I'll wait for an official
> >     3 +1s and no -1s before I start deleting stuff)
> >   - Return values for the add, subtract, and inc functions
> >     (I haven't figured out a way to implement these
> >     efficiently)
> > 
> > Brian
> > 
> > 
> 
> 
> The patch simply #defines the apr_atomic_t as LONG.
> 

Dissregard the previous patch ;-).

MT.

RE: [PATCH] Updated atomic API

[Mladen Turk <mt...@apache.org>]

> -----Original Message-----
> From: Brian Pane
> 
> Changes not yet made:
>   - Removal of the old API (I saw two comments in favor
>     of this, including my own; I'll wait for an official
>     3 +1s and no -1s before I start deleting stuff)
>   - Return values for the add, subtract, and inc functions
>     (I haven't figured out a way to implement these
>     efficiently)
> 
> Brian
> 
> 

I have a patch (send It back in April) that enable to use the atomic
from C++ on WIN32.
The problem is the fact that C++ distinguishes unsigned int and LONG
mixage as an error.

Unlike the other platforms for WIN32 the apr_atomic_t is 'typedefed' so
later in the header it is reverted from LONG to apr_uint32_t, so the
IntelockedXX functions gets apr_uint32_t as a param, and C++ reports
that as an error.

The patch simply #defines the apr_atomic_t as LONG.

MT.