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

[Werner Johansson]

----- 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).

/Werner