Re: New audio output framework. Draft 1.

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 <woofpingtel.com> wrote:

> Woof!
> 
> On Wed, 21 Mar 2007 09:50:02 -0400, Daniel Petrie
<dpetriesipez.com>
> 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
sipxtapi-devlist.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/