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/
