[MPlayer-dev-eng] [PATCH] Fix dead lock in ao_macosx when switch stream format.

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Tue Nov 6 21:17:03 CET 2007


Hello,
On Tue, Nov 06, 2007 at 01:50:16AM +0800, Ulion wrote:
> 2007/11/5, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
[...]
> > I am not yet convinced this isn't a ugly hack instead of a proper fix.
> > I also think that such a solution means that a conditional is required
> > whereas my solution should allow using the more lightweight signals if
> > someone cares (I doubt it, this looks hardly performance-critical in any
> > way, and portability does not really matter either).
> 
> The mutex lock is useless, don't you think so? Since it's useless,
> remove it will be a proper fix, leave the lock code in callback will
> keep some dead lock risk if on some platform the get format call after
> cond wait also blocked because the format change callback didn't
> return. The callback singal caller is only one, and just need notify
> us format changed, need not grab the mutex lock, isn't it?

Actually, no. pthread condition stuff behaves like what I considered
"more lightweight signals".
The man page says:
> The pthread_cond_broadcast() and pthread_cond_signal() functions shall have
> no effect if there are no threads currently blocked on cond.

So removing the lock in the callback means that the signal can be
completely missed (due to the main thread being somewhere in the code
before or in-between pthread_cond_timedwait), so the worst-case
behaviour would be like just removing the callback completely, and
changes in the system scheduler could make that worst case quite likely.

Greetings,
Reimar Döffinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20071106/f2eb608d/attachment.pgp>


More information about the MPlayer-dev-eng mailing list