-----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-----