[MPlayer-dev-eng] [PATCH] threaded cache, round 2

[Reimar Döffinger]

On Sun, Jan 29, 2012 at 06:20:11PM +0100, Dan Oscarsson wrote:
> sön 2012-01-29 klockan 11:54 +0100 skrev Reimar Döffinger:
> > 
> > I don't think that will work, on some architectures there is no
> > guarantee when writes will happen, so the following is possible without
> > locks:
> 
> > Note that this _should_ not be possible on x86 since it has quite a
> > strict coherency model (even though it is still confusing and risky
> > to rely on such stuff).
> 
> Yes, I missed the cache coherency problem of which people are very
> uncertain of on the net. It looks like I have to have all setting and
> checking of do_work within the mutex lock to ensure cache coherency.
> But even there people on the net are somewhat uncertain about cache
> coherency.
> Though, it could probably be done more efficient on x86.
> 
> This also means that "atomic operations" have to ensure cache coherency.
> 
> > However in the case of your code you run into another issue:
> > you did not mark do_work as volatile, thus since the assignment is
> > outside the locks, the _compiler_ is perfectly free to actually move
> > the assignment to after the cache reading.
> 
> Yes, fixed.
> 
> Attached is a new version.

Unfortunately the approach in itself breaks the
stream_time_pos/stream_time_len update mechanism so the core
might get severely outdated values of these.