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

Ulion ulion2002 at gmail.com
Wed Nov 7 14:00:18 CET 2007


2007/11/7, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> 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.
>

OK, I got a no lock version of fix now, it also works fine without
problems, please check it.

-- 
Ulion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ao_osx_chg_fmt_dead_lock2.diff
Type: text/x-diff
Size: 3240 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20071107/a73d4385/attachment.diff>


More information about the MPlayer-dev-eng mailing list