Perhaps you missed my descriptive text below (included again below) the bullets describing the locking or perhaps the text was not clear. You are correct if something waiting for the device lock holds manager lock, the device lock will never get release and the two will deadlock. However the context waiting for the device lock must release the manager while it is waiting for the device lock to be freed. The context waiting for the device lock can be notified or it can poll to check if the device lock is free. If it polls it must take and release the manger lock.
>This approach takes the large scoped lock on the manager for a short > period of time only long enough to take the lock on the specific > connection/device. If the connection/device lock is not available, > the manager lock is released and you wait or poll to re-attempt to > take theconnection/device using the prior process. We actually use > this locking pattern in any places in sipX, most recently in the > MpInputDeviceManager. --- Andy Spitzer <[EMAIL PROTECTED]> wrote: > Woof! > > On Wed, 21 Mar 2007 09:50:02 -0400, Daniel Petrie <[EMAIL PROTECTED]> > wrote: > > There is still locking > > required on the manager and connection. However this can be made > > fairly granular to avoid cross device blocking using the following > > approach: > > take lock on the manager > > take the lock on the connection/device, > > release the manager lock > > invoke the frame push to the driver > > take lock on the manager > > release the lock on the connection/device, > > release the manager lock > > This locking approach is prone to "deadly embrace". Let me explain > by > numbering the above steps and walking through a specific scenario: > > 1. take lock on the manager > 2. take the lock on the device > 3. release the manager lock > 4. invoke the frame push to the driver > 5. take lock on the manager > 6. release the lock on the device, > 7. release the manager lock > > There are two threads, A and B that want to access the same device. > > Thread A: > 1. takes a lock on the manager > 2. takes the lock on the device > 3. releases the lock on the manager > 4. invokes the frame push to the driver > > At this point, thread A holds the device lock, but NOT the manager > lock. > Now thread B comes along and wants to do something with the device: > > Thread B: > 1. takes a lock on the manager > 2. Attempts to take the lock on the device > (BLOCKED, because thread A owns the device lock) > > And now thread A tries to release the device lock: > > Thread A: > 5. Attempts to take the lock on the manager > (BLOCKED, because thread B owns the manager lock) > > At this point, Thread A holds the device lock, and thread B holds the > manager lock. This is classic deadly embrace: A cannot continue until > B > releases the manager lock, and B cannot continue until A releases the > device lock. > > Fine grained locking always seems so appealing, but it is very hard > to implement > correctly! > > --Woof! > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
