[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