Re: [recon-devel] Thread safe of recon for srtp
According to POSIX *all* accesses to shared variables
must be protected by some synchronization. It does
not matter is it a read or a write, because if you do not
protect access, then compiler during optimization may
do things you may have never thought about, and
some hardware is able to do even more strange things.
So I'd recommend to follow POSIX rules if you want
your software to be portable across different hardware
and compilers. You can find slides with examples of
what may happen if you do not follow this rule.
You may start reading from "Threads Cannot be
Implemented as a Library" (though this article is a bit
off-topic), then follow references and google for more
on keywords.
2009/1/19 Karlsson <boost.regex@xxxxxxxxx>:
> So I think maybe there can do optimization, likes:
>
> err_status_t
> MediaStream::srtpProtect(void* data, int* size, bool rtcp)
> {
> {
> err_status_t status = err_status_no_ctx;
>
> Lock lock(mMutex);
> if (mSRTPSessionOutCreated == false)
> {
> return err_status_no_ctx;
> }
> }
>
> if(rtcp)
> {
> status = srtp_protect_rtcp(mSRTPSessionOut, data, size);
> }
> else
> {
> status = srtp_protect(mSRTPSessionOut, data, size);
> }
>
> return status;
> }
>
> Because the srtp functions will take long time ?
>
>
>
> On Tue, Jan 20, 2009 at 1:28 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
>>
>> That is correct.
>>
>> 2009/1/19 Karlsson <boost.regex@xxxxxxxxx>:
>> > Hi, I think the libSRTP is thread safe and does not requires mutex, why
>> > in
>> > the mediastream.cxx of recon there has a lock ?
>> > Likes MediaStream::srtpProtect and MediaStream::srtpUnprotect,
>> > MediaStream::createOutboundSRTPSession etc...
>> >
>> > I think this lock is used for mSRTPSessionOutCreated,
>> > mSRTPSessionInCreated
>> > and independent the srtp, right ?
>> >
>> > Thanks
>> >
>> > _______________________________________________
>> > recon-devel mailing list
>> > recon-devel@xxxxxxxxxxxxxxx
>> > List Archive: http://list.resiprocate.org/archive/recon-devel/
>> >
>
>
> _______________________________________________
> recon-devel mailing list
> recon-devel@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>
--
Regards,
Alexander Chemeris.
SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000