Philippe wrote: > Hi Benny, > > I agree with you that only one transaction could run at a given time; > however some variables (such as timer or has_tsx) of the regc structure can > be tested or changed from the APIS calls. Yeah you have a point there. The original idea of not using mutex in regc was because operations should be serialized by 8-bit boolean flags, and (I heard) operation to 8-bit variables should be atomic. But it seems that with recent modifications/bug fixes in regc, this rule may not hold anymore (such as the timer, which I think was added only quite recently). So I guess adding a mutex will not hurt, and it even should add robustness to the code. Added http://www.pjsip.org/trac/ticket/418 to implement this. Thanks for catching this, -benny > Best regards > > Philippe Leuba > > > -----Original Message----- > From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] > On Behalf Of Benny Prijono > Sent: vendredi, 16. novembre 2007 09:03 > To: pjsip embedded/DSP SIP discussion > Subject: Re: Client registration layer locking > > Hi Philippe, > > the lack of mutex protection in regc was pretty much intentional, as > once the regc is created, all updates to the structure will be done > from the transaction callback. And since regc does not allow more > than one transactions to run at the same time, we should be safe. > Well at least that's the way it was supposed to work. > > cheers, > -benny > > Philippe wrote: >> Hi, >> >> By examining the pjsip-ua layer providing the client registration >> (regc), we notice that no locking mechanism is used. >> >> It seems that this can cause some potential risks if we are using worker >> threads as the reception callback or the timer can access the regc >> structure at the same time that the regc APIs. >> >> Other layers, such as the invite or xfer use the lock of the underlying >> dialog. >> >> >> >> Philippe Leuba >> >> eyeP Media SA >> > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -- Benny Prijono http://www.pjsip.org
