On Wed, 2009-07-29 at 16:13 -0400, Scott Lawrence wrote: > This looks good to me. It may be that you can reduce the time that the > set lock is held by modifying one rule: > > > Pattern for an externally-called method that does not affect > timers: > > seize the set lock > look up the object in question > seize the object lock > release the set lock > perform the operations > release the object lock > > whether or not this is worth the extra complexity depends on whether or > not these are common and how long they take.
That doesn't save much, now that there is only one object lock -- to read or write an object, one must hold the object lock. So releasing the set lock while still holding the object lock doesn't let any other method proceed to completion. (I think that if the system were larger and scaling was an issue, we could outfit all the objects in the hierarchy with read/write locks in a straightforward and safe manner. The ugly part of the problem is handling the timers and their event routines, and I don't think that gets any worse if the containing structure of objects gets larger or more complicated.) Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
