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

[imran ahmed]

I think the race condition would still exist even if you use an atomic
operation because of the sprintf statement after it. Though the unique
id might be incremented atomically it would still end up being the
same in the sprintf call.

regards
Imran

On 12/30/05, Luigi Rizzo <rizzo at icir.org> wrote:
> 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
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>