You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ian Holsman <ia...@apache.org> on 2002/02/10 18:16:30 UTC
Atomic operations
hi.
I would really like to get atomic operations into the APR.
having atomic_add would allow nifty things like virtual-host stats,
and reference counting (among others)
I've noticed that linux supports them out of the box via
atomic_add in <asm/atomic.h>
NT has there version in Interlock...
GCC v3 also has gcc-3.0/include/g++-v3/sparcv9-sun-solaris2.8/bits
for solaris, so I'm assuming that everywhere GCC v3 has been ported it
will be available.
I remember the FreeBSD has something similiar
so that leaves the others, which I'm sure have somthing like this.
the alternative for non-native atomic support is a mutex or
specifcying a --disable-smp on the command line for configure which
will disable the mutex on single CPU boxes.
what do you think guys??
..Ian
Re: Atomic operations
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Feb 10, 2002 at 09:16:30AM -0800, Ian Holsman wrote:
> hi.
> I would really like to get atomic operations into the APR.
>
> having atomic_add would allow nifty things like virtual-host stats,
> and reference counting (among others)
>
> I've noticed that linux supports them out of the box via
> atomic_add in <asm/atomic.h>
>
> NT has there version in Interlock...
> GCC v3 also has gcc-3.0/include/g++-v3/sparcv9-sun-solaris2.8/bits
> for solaris, so I'm assuming that everywhere GCC v3 has been ported it
> will be available.
>
> I remember the FreeBSD has something similiar
>
>
> so that leaves the others, which I'm sure have somthing like this.
> the alternative for non-native atomic support is a mutex or
> specifcying a --disable-smp on the command line for configure which
> will disable the mutex on single CPU boxes.
>
> what do you think guys??
I think this is going to screw us with respect to target/compiler/OS
combinations. AFAIK, Linux's ASM kernel constructs works only with
gcc. Assembler blocks are going to be dependent on the machine type,
the compiler, and the operating system.
I'd wish we could do this within ANSI C, but I know that we can't.
I won't stand in your way, but I'll cast -0 as there is no way
I'm helping out. This will get real messy real fast. -- justin
Re: Atomic operations
Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Holsman <ia...@apache.org> writes:
> hi.
> I would really like to get atomic operations into the APR.
sounds reasonable...
> so that leaves the others, which I'm sure have somthing like this.
> the alternative for non-native atomic support is a mutex or
> specifcying a --disable-smp on the command line for configure which
> will disable the mutex on single CPU boxes.
>
> what do you think guys??
I don't buy the --disable-smp argument. The mutex (or the type of
serialization done by the CPU primitive) is also there to protect
against getting timesliced at an inopportune point in the update
sequence. Otherwise another dispatchable unit can progress merrily
through the same update sequence and result in an inconsistent state
once the first dispatchable unit gets the CPU back and finishes the
sequence.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Atomic operations
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Feb 10, 2002 at 09:16:30AM -0800, Ian Holsman wrote:
> hi.
> I would really like to get atomic operations into the APR.
>
> having atomic_add would allow nifty things like virtual-host stats,
> and reference counting (among others)
+1 in concept, I think it would be very useful but inside and outside
of APR.
-aaron
Re: Atomic operations
Posted by Harrie Hazewinkel <ha...@lisanza.net>.
--On Monday, February 11, 2002 8:41 AM -0800 Ian Holsman <ia...@apache.org>
wrote:
>>>
>>
>> Having done a lot of counting while making SNMP modules, I never needed
>> some king of locking. OK, I admit it is maybe a bit of overhead, but you
>> could create a pipe/channel that logs all required information to some
>> extra thread/process that collects this all for you. Then by having
>> that thread/process doing counting you can do either lock it local
>> (local as in the process/thread) or just serialize all counting messages
>> coming from the pipe.
>>
>
> The reason I'm doing it is more for reference counting. I need to know
> when a object has no more requests against it, so I can kill it.
I see what you mean. That is indeed better to do with some
overall locking by means of atomic operations. However, a potential
problem of deadlock can arise.
Then a solution could be to create some pipe that logs a claim
and release operations. Although, I admit this could create
some additional load. For each transaction.
Another solution could be to have for each thread/process -
that handles a request - its own registration and the management
module collects all these small pieces of data when needed.
Both solutions create little load per request and more for
the management solution. That is not a real problem, since
management always costs resources while it is not the core
task of the application.
Hope this helps,
Harrie
mailto: harrie@lisanza.net http://www.lisanza.net/
Internet Management Consulting
Re: Atomic operations
Posted by Ian Holsman <ia...@apache.org>.
Harrie Hazewinkel wrote:
> --On Sunday, February 10, 2002 9:16 AM -0800 Ian Holsman <ia...@apache.org>
> wrote:
>
>
>>hi.
>>I would really like to get atomic operations into the APR.
>>
>>having atomic_add would allow nifty things like virtual-host stats,
>>and reference counting (among others)
>>
>
> Having done a lot of counting while making SNMP modules, I never needed
> some king of locking. OK, I admit it is maybe a bit of overhead, but you
> could create a pipe/channel that logs all required information to some
> extra thread/process that collects this all for you. Then by having
> that thread/process doing counting you can do either lock it local
> (local as in the process/thread) or just serialize all counting messages
> coming from the pipe.
>
The reason I'm doing it is more for reference counting. I need to know
when a object has no more requests against it, so I can kill it.
>
>
> Harrie
>
> mailto: harrie@lisanza.net http://www.lisanza.net/
> Internet Management Consulting
>
>
Re: Atomic operations
Posted by Harrie Hazewinkel <ha...@lisanza.net>.
--On Sunday, February 10, 2002 9:16 AM -0800 Ian Holsman <ia...@apache.org>
wrote:
> hi.
> I would really like to get atomic operations into the APR.
>
> having atomic_add would allow nifty things like virtual-host stats,
> and reference counting (among others)
Having done a lot of counting while making SNMP modules, I never needed
some king of locking. OK, I admit it is maybe a bit of overhead, but you
could create a pipe/channel that logs all required information to some
extra thread/process that collects this all for you. Then by having
that thread/process doing counting you can do either lock it local
(local as in the process/thread) or just serialize all counting messages
coming from the pipe.
Harrie
mailto: harrie@lisanza.net http://www.lisanza.net/
Internet Management Consulting
RE: Atomic operations
Posted by Ryan Bloom <rb...@covalent.net>.
> Jeff Trawick wrote:
> > "Ryan Bloom" <rb...@covalent.net> writes:
> >
> >
> >>If we are on a platform that doesn't support atomic add/set, just do
> >>what Windows does. Namely, have a global mutex that is set for any
> >>atomic add or set command. The add/set is only atomic across other
> >>threads/process using the same add/set functions, but that should be
> >>good enough.
> >>
> >
> > not scalable...
> >
> > the app would be better off rolling their own support
> >
> >
>
>
> The way I was thinking of implementing the atomic to implement a
> 'apr_atomic_t' which is only 24bits wide (linux only supports 24 bits)
>
> this would be mapped to the OS's atomic type if available. otherwise
it
> would be someting like
>
> typedef struct {
> apr_lock_t lock; /* either a mutex or some home grown spinlock*/
> int value;
> }
>
> which would introduce a apr_atomic_init/apr_atomic_term
>
> I'll work on getting the 'generic' version up first, and
> make sure it works in a speedy way,
>
> no my main question .. how do OS's handle multiple locks. I don't
think
> solaris has a issue with 1000's of locks created is there some kind of
> performance penalty in creating 100/1000 locks instead of using a
single
> lock?
Every lock that you create will use some system resource, either a file
descriptor, or a semaphore. The more you create the fewer that are
available for other things. On some platforms that may mean that you
need to tweak the kernel to get enough locks. I am thinking of HPUX in
particular.
My opinion is that one lock is the only way to do this without using too
many resources to make it really work. The real question, is what
platforms don't support some atomic operation already, and how prevalent
are they? Even BeOS supports atomic operations, because we use them in
some of the APR code.
Ryan
Re: Atomic operations
Posted by Ian Holsman <ia...@apache.org>.
Jeff Trawick wrote:
> "Ryan Bloom" <rb...@covalent.net> writes:
>
>
>>If we are on a platform that doesn't support atomic add/set, just do
>>what Windows does. Namely, have a global mutex that is set for any
>>atomic add or set command. The add/set is only atomic across other
>>threads/process using the same add/set functions, but that should be
>>good enough.
>>
>
> not scalable...
>
> the app would be better off rolling their own support
>
>
The way I was thinking of implementing the atomic to implement a
'apr_atomic_t' which is only 24bits wide (linux only supports 24 bits)
this would be mapped to the OS's atomic type if available. otherwise it
would be someting like
typedef struct {
apr_lock_t lock; /* either a mutex or some home grown spinlock*/
int value;
}
which would introduce a apr_atomic_init/apr_atomic_term
I'll work on getting the 'generic' version up first, and
make sure it works in a speedy way,
no my main question .. how do OS's handle multiple locks. I don't think
solaris has a issue with 1000's of locks created is there some kind of
performance penalty in creating 100/1000 locks instead of using a single
lock?
..Ian
Re: Atomic operations
Posted by Jeff Trawick <tr...@attglobal.net>.
"Ryan Bloom" <rb...@covalent.net> writes:
> If we are on a platform that doesn't support atomic add/set, just do
> what Windows does. Namely, have a global mutex that is set for any
> atomic add or set command. The add/set is only atomic across other
> threads/process using the same add/set functions, but that should be
> good enough.
not scalable...
the app would be better off rolling their own support
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: Atomic operations
Posted by Ryan Bloom <rb...@covalent.net>.
> hi.
> I would really like to get atomic operations into the APR.
++1, I haven't wanted this for a long time.
> so that leaves the others, which I'm sure have somthing like this.
> the alternative for non-native atomic support is a mutex or
> specifcying a --disable-smp on the command line for configure which
> will disable the mutex on single CPU boxes.
If we are on a platform that doesn't support atomic add/set, just do
what Windows does. Namely, have a global mutex that is set for any
atomic add or set command. The add/set is only atomic across other
threads/process using the same add/set functions, but that should be
good enough.
Ryan