[asterisk-users] [asterisk-dev] Locking, coding guidelines addition

[Grey Man]

On Sun, Jul 6, 2008 at 4:11 AM, Russell Bryant <russell at digium.com> wrote:
>
> 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.