VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
greymanvoip at gmail.com Guest
|
Posted: Sat Jul 05, 2008 10:59 pm Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sun, Jul 6, 2008 at 4:11 AM, Russell Bryant <russell at digium.com> wrote:
Quote: |
On Jul 5, 2008, at 7:59 PM, Grey Man wrote:
Having a thread per channel _absolutely does NOT_ remove the need for
locking to synchronize access to channel data structures.
|
It does if only one thread needs to access the channel data
structures. Perhaps I should have been clearer about the use of
"channel". Rather than being the overall SIP channel or IAX channel
driver I was referring to creating a new thread at the point a channel
driver creates a new ast_channel structure. After the structure and
new thread have been initialised by the channel driver the only thread
allowed to access it the structure is its associated thread.
At the end of the day we'd all like to see the locking issue
eliminated from Asterisk. My worry would be that putting in place
stringent guidelines dealing with the way channel data must be locked
and unlocked will mean the problem will continue to occur every time a
new developer adds an new module and is not aware, doesn't understand
or forgets the guidelines. A more idealistic fix would be to provide a
safe, simple way to access the channel data in the first place hence
the suggestion of one channel struct pre thread suggestion which
appears to be how FS have solved the problem. One of the very reasons
this thread came up (again) is that one of the experienced Asterisk
developers seemingly put some locks in wrong order pointing to the
fact that the problem may possibly be with the locking mechanism
rather than the developer.
I don't pretend to have anywhere near the expertise you or others have
in the architecture of the Asterisk core and am merely attempting to
contribute. I do have my fair share of experience writing
multi-threaded applications and the best locking mechanism crosses
both problem domain and language. If such ideas have already been
considered and aren't suitable fair enough I'm not trying to tell you
how to do your job, i.e. it's not presonal .
Regards,
Greyman. |
|
Back to top |
|
|
sean.bright at gmail.com Guest
|
Posted: Sat Jul 05, 2008 10:59 pm Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
Steve Totaro wrote:
Quote: | There must be a reason.... What is it?
|
That is the question that *you* are being asked.
A competing project is getting better performance and you believe it has
to do with locking. What specific changes do you suggest making to the
locking infrastructure in Asterisk in order to improve it's scalability?
--
Sean Bright
sean.bright at gmail.com |
|
Back to top |
|
|
stephen.l.davies at gm... Guest
|
Posted: Sun Jul 06, 2008 8:08 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
2008/7/6 Grey Man <greymanvoip at gmail.com>:
Quote: | From what I can gather the suggestion from the FS approach is that
each Asterisk channel should be handled after by it's own unique
thread and save the need for any locking on the channel data
structures in the first place.
| After a quick grep, there are lots of mutex locks and unlocks in the FS
code. As you would expect.
I guess Steve Totaro's "grunt techs" know that, whilst Steve has drunk the
koolaid (and is trolling, anyway).
Nevertheless - the suggestion as I understand it is that there is less
contention for locks in FS due to the design choice that one thread is
created that handles one active channel. I guess the theory is that
_everything_ done on that channel is done in that thread. By contrast, we
have a mix of design styles like the worker threads, network threads etc.
But we don't have evidence that contention for mutexes (aka locks) is
slowing Asterisk down. So it there is a big performance different it will
probably be elsewhere - like the linked lists that are already getting
attention.
My curiosity is piqued to do a proper comparison of Asterisk and Freeswitch
with a realistic workload and compare results (and profile Asterisk if there
is a big difference.
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080706/8fe44015/attachment.htm |
|
Back to top |
|
|
stotaro at totarotechn... Guest
|
Posted: Sun Jul 06, 2008 9:07 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sun, Jul 6, 2008 at 9:08 AM, Stephen Davies
<stephen.l.davies at gmail.com> wrote:
Quote: |
2008/7/6 Grey Man <greymanvoip at gmail.com>:
Quote: |
From what I can gather the suggestion from the FS approach is that
each Asterisk channel should be handled after by it's own unique
thread and save the need for any locking on the channel data
structures in the first place.
|
After a quick grep, there are lots of mutex locks and unlocks in the FS
code. As you would expect.
I guess Steve Totaro's "grunt techs" know that, whilst Steve has drunk the
koolaid (and is trolling, anyway).
|
Wrong again.
Quote: |
Nevertheless - the suggestion as I understand it is that there is less
contention for locks in FS due to the design choice that one thread is
created that handles one active channel. I guess the theory is that
_everything_ done on that channel is done in that thread. By contrast, we
have a mix of design styles like the worker threads, network threads etc.
But we don't have evidence that contention for mutexes (aka locks) is
slowing Asterisk down. So it there is a big performance different it will
probably be elsewhere - like the linked lists that are already getting
attention.
|
Lack of evidence means absolutely nothing, besides you are clueless.
Quote: |
My curiosity is piqued to do a proper comparison of Asterisk and Freeswitch
with a realistic workload and compare results (and profile Asterisk if there
is a big difference.
Steve
|
So again, I pose the question, why a 10X improvement?
I will compare the two on the same hardware, but for what its worth,
(the name that cannot spoke) shows how much slower Asterisk is.
Thanks,
Steve Totarao |
|
Back to top |
|
|
tzafrir.cohen at xorco... Guest
|
Posted: Sun Jul 06, 2008 9:30 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sun, Jul 06, 2008 at 10:07:32AM -0400, Steve Totaro wrote:
Quote: | On Sun, Jul 6, 2008 at 9:08 AM, Stephen Davies
|
Quote: | Quote: | My curiosity is piqued to do a proper comparison of Asterisk and Freeswitch
with a realistic workload and compare results (and profile Asterisk if there
is a big difference.
Steve
|
So again, I pose the question, why a 10X improvement?
|
What 10X improvement? Please be more specific. And please point to a
test that can be reproduced so the impact of changes can be tested.
Quote: |
I will compare the two on the same hardware, but for what its worth,
(the name that cannot spoke) shows how much slower Asterisk is.
|
Fine. I think that a good benchmark can always help.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir |
|
Back to top |
|
|
stotaro at totarotechn... Guest
|
Posted: Sun Jul 06, 2008 9:57 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sat, Jul 5, 2008 at 11:59 PM, Sean Bright <sean.bright at gmail.com> wrote:
Quote: | Steve Totaro wrote:
Quote: | There must be a reason.... What is it?
|
That is the question that *you* are being asked.
A competing project is getting better performance and you believe it has
to do with locking. What specific changes do you suggest making to the
locking infrastructure in Asterisk in order to improve it's scalability?
--
Sean Bright
sean.bright at gmail.com
|
Call me Mr.Obvious, but I propose figuring out why it is faster (and
obviously get FS to sign away any righs).
Obviously, you did not visit the site enough to understand, or your
retention is lacking.
Besides that, google is you friend.
http://www.anders.com/cms/266/Asterisk.vs.FreeSWITCH
Thanks,
Steve Totaro
Adopt FS's method..... It is like pulling teeth with guys. |
|
Back to top |
|
|
stotaro at totarotechn... Guest
|
Posted: Sun Jul 06, 2008 10:02 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sun, Jul 6, 2008 at 10:57 AM, Steve Totaro
<stotaro at totarotechnologies.com> wrote:
Quote: | On Sat, Jul 5, 2008 at 11:59 PM, Sean Bright <sean.bright at gmail.com> wrote:
Quote: | Steve Totaro wrote:
Quote: | There must be a reason.... What is it?
|
That is the question that *you* are being asked.
A competing project is getting better performance and you believe it has
to do with locking. What specific changes do you suggest making to the
locking infrastructure in Asterisk in order to improve it's scalability?
--
Sean Bright
sean.bright at gmail.com
|
Call me Mr.Obvious, but I propose figuring out why it is faster (and
obviously get FS to sign away any righs).
Obviously, you did not visit the site enough to understand, or your
retention is lacking.
Besides that, google is you friend.
http://www.anders.com/cms/266/Asterisk.vs.FreeSWITCH
Thanks,
Steve Totaro
Adopt FS's method..... It is like pulling teeth with guys.
|
Maybe this will help: http://blogs.zdnet.com/Greenfield/?p=214
Thanks,
Steve Totaro |
|
Back to top |
|
|
stotaro at totarotechn... Guest
|
Posted: Sun Jul 06, 2008 10:12 am Post subject: [asterisk-users] [asterisk-dev] Locking, coding guidelines a |
|
|
On Sun, Jul 6, 2008 at 10:57 AM, Steve Totaro
<stotaro at totarotechnologies.com> wrote:
Quote: | On Sat, Jul 5, 2008 at 11:59 PM, Sean Bright <sean.bright at gmail.com> wrote:
Quote: | Steve Totaro wrote:
Quote: | There must be a reason.... What is it?
|
That is the question that *you* are being asked.
A competing project is getting better performance and you believe it has
to do with locking. What specific changes do you suggest making to the
locking infrastructure in Asterisk in order to improve it's scalability?
--
Sean Bright
sean.bright at gmail.com
|
Call me Mr.Obvious, but I propose figuring out why it is faster (and
obviously get FS to sign away any righs).
Obviously, you did not visit the site enough to understand, or your
retention is lacking.
Besides that, google is you friend.
http://www.anders.com/cms/266/Asterisk.vs.FreeSWITCH
Thanks,
Steve Totaro
Adopt FS's method..... It is like pulling teeth with guys.
| This may help. http://blogs.zdnet.com/Greenfield/?p=214 |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|