FYI Re: wined3d_mutex

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-03-17 15:30, schrieb Max TenEyck Woodbury:
> Well, at least as fine as native.  Finer might be safer since there
> is little besides direct examination of the native execution stream
> (a big NONO!) that assures that all grain boundaries have been
> identified.
An application may (inadvertently rather than knowingly) expect d3d to
block the execution of one of its threads and corrupt internal data if
we don't. Unless we don't know of any such case we don't have to copy
every stupid behavior native has, but there's also no point in being
extra clever about things when applications don't expect d3d to do that.

> OK.  I believe you, but exactly what kind of lock is it and how did
> you go about identifying it?  The fact that 'we' hold it during the
> call backs is something that bothered me.  I also noted that 'we'
> sometimes take it out twice which also makes me think its use is
> rather superficial.

Something like this:

event e1 = cleared, e2 = cleared;
IDirectDraw ddraw1, ddraw2;

Thread 1:
{
    Start thread 2;
    Wait for event e1;
    ddraw1->AddRef();
    Signal event e2;
    return;
}

Thread 2:
{
    ddraw2->EnumSurfaces (callback);
    callback:
    {
        Signal event e1;
        Wait for event e2 - expect a timeout;
    }
}

The Addref call in thread 1 does not finish until the EnumSurfaces
callback finishes. Since the callback waits for e2 this pseudocode
deadlocks. The deadlock is detected by a timed out wait with a
reasonably large (e.g. 500ms) wait time.

This deadlock even happens with two totally unrelated ddraw objects,
and functions that shouldn't need a lock like AddRef. (AddRef can just
be implemented using interlocked increment ops like in Wine.)

Alexandre said there was no point in having such a test in the tree
unless we find an application that depends on the coarse locking
behavior. You can search wine-patches for the test, I think I
submitted it somewhen in late 2006 or 2007.

The same can be done in d3d9, but the AddRef and Release methods of an
IUnknown * passed to SetPrivateData are the only case I know of where
those libraries call application code. I expect d3d9 to be better wrt
concurrency than ddraw. But it needs tests, not suspicions.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTJwuxAAoJEN0/YqbEcdMw1YIP/0VbBi/A0yRV9rRSNP9nncrl
sul2ChIE0161Xk3o+9rBnH2DJCyt7a1kx6/AkhZqnhid8UNWFCQxbtDdMpP8w/pQ
R1Q2nofj82AaQAJGoIxC7WgwzJAmwjchCO3RWzszpipORXHro5VWMqBT8ZeHrQrT
Tt4hsEdzgfj5bwcM4V/ja0Nm78aM+mLbE6WJbFHoo/u+M0gnhuDCViBMS2TeT50h
I3NmAJOu6fIvYdFEpgTQBqprAAR4KZbwWxcie2IzoMoc0qygSjpWDshIlBczxfhZ
x3wwbH52EZi5+Mpa6BCsm3DWZ14SjXZ9chVegYcG1svkrDzP7xaQ3COKRRyHiv5o
40Vq4RU95GnZNLP8BYZDKqCgYd1a/tOTrpgyS+QPxTJEtTaKaXjxfSK7ApTQ9cbY
LsQmhrdvpBxjX/YGZOmr5LbNJJ/fHFLKlBejBS24cB11ZTzptY1z6tnVNKQ2KAM6
pMSwj3R0DhehN4y1tQOWbSYwy3pi6K/OsziuX3MU17zcx5Haom6z7amV/OfRjwlX
/IxVQjJ6v9K9xjkFk2ymTxcnp/WuKiZaHvN2SshQr63xFQKgsbVUMymcW/aNXkmc
E9w9fjRcwM4ch+nmT7ifvQkHsnf7nuiBa9+bZe08QrkmPeBV8aAz1ysByyMXTsxc
OndGfGOhTu+utYvrLkVt
=WmQv
-----END PGP SIGNATURE-----