At 12:25 AM 1/28/2008, you wrote: >On 1/28/08, David Clark <vdc1048 at tx.rr.com> wrote: > > Ok got an idea here. It has to do with lock_count which associated > > with the lock. > > > > enter_lock(): > > increments lock count > > tries to get the OS lock. > > > > leave_lock(): > > decrements lock count > > releases the OS lock. > > if lock_count==0 and marked for deletion // was intended to be > > deleted elsewhere do it now. > > delete lock. > > > >Doesn't the code above potentially have problem, as it checks for >lock_count and performs deletion without acquiring the mutex? Ok with the existing mechanism is clear the delete of the mutex needs to be delayed. Because once you block on a mutex the OS expects it to be there until unblocked.. Then there is the lesser issue of the release on that mutex that comes down further in the existing code. Well, lock_count becomes now many locks + pending locks. The idea is simply to delay the deletion if there is locks or pending locks, until the last release is completed. Now lock_count might need to be more complex to avoid an issue with one thread being in destroy_lock() testing lock count and finding 0 while thread two is in enter_lock() but not yet incrementing the lock. Is that what your talking about Benny? >cheers, > -benny > > > > destory_lock(): > > if lock_count==0 // we can delete now > > remove lock from memory > > set pointer to zero. > > else > > mark lock for deletion. // we can delete somewhere else. > > > > > > >cheers, > > > -benny > >_______________________________________________ >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 > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.19.12/1245 - Release Date: >1/26/2008 3:45 PM
