[Asterisk-Dev] Race issue in channel.c involving uniqueint onAsterisk 1.2.1

[Luigi Rizzo]

On Fri, Dec 30, 2005 at 04:13:27PM +0100, Werner Johansson wrote:
> ----- Original Message ----- 
> From: "Tilghman Lesher" <tilghman at mail.jeffandtilghman.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Friday, December 30, 2005 4:02 PM
> Subject: Re: [Asterisk-Dev] Race issue in channel.c involving uniqueint 
> onAsterisk 1.2.1
> 
> 
> > On Friday 30 December 2005 07:12, Luigi Rizzo wrote:
> >> I think the proper course of action is to wrap the atomic ops
> >> into macros, and then let the common header implement the
> >> locking in the proper way, with fallback to the above
> >> sequence only for unknown architectures.
> >>
> >> FreeBSD (and i suppose linux as well) has example code
> >> for i386 and others in the machine/atomic.[ch] files
> >
> > This appears to be FreeBSD-specific (or BSD-specific).  There are
> > no such macros on Linux.
> >
> > -- 
> > Tilghman
> 
> Even so, Luigi Rizzo has a point when it comes to performance - would it be 
> a good idea to have something like that implemented as Asterisk support 
> functions? It can then be generic "lock/unlock" or more optimized versions 
> on certain architectures/OSes?
> 
> But considering how much that is done everytime you bring a new channel up, 
> how much difference does the mutex lock/unlock really make cpu cycle wise - 
> it's only done once, not in any form of loop (in that case it would be much 
> more time critical).

it probably doesn't matter much for this specific case,
so your patch is certainly welcome.

I just took the opportunity to raise the issue before everyone starts
implementing his own version of atomic_add().

cheers
luigi