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

Luigi Rizzo rizzo at icir.org
Fri Dec 30 09:40:50 MST 2005


On Fri, Dec 30, 2005 at 10:22:11AM -0600, imran ahmed wrote:
> 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.

you are absolutely right.
In fact in these cases one should use something like

	call_id = atomic_fetchadd_int(&uniqueid, 1);

and then call_id is the unique value.
On i386 and amd64 (from freebsd machine/atomic.h) we have

/*
 * Atomically add the value of v to the integer pointed to by p and return
 * the previous value of *p.
 */
static __inline u_int
atomic_fetchadd_int(volatile u_int *p, u_int v)
{

        __asm __volatile (
        "       lock                    "
        "       xaddl   %0, %1 ;        "
        "# atomic_fetchadd_int"
        : "+r" (v),                     /* 0 (result) */
          "=m" (*p)                     /* 1 */
        : "m" (*p));                    /* 2 */
 
        return (v);
}

not sure about other architectures.

	cheers
	luigi



More information about the asterisk-dev mailing list