Mike Hearn wrote:
On Wed, 21 Jul 2004 13:08:57 +0300, Shachar Shemesh wrote:
Are there any restrictions in synchronizing wine generated threads (generated through the win32 api) using the pthreads library native calls?
On NPTL (pthread) systems I think this should work. On kthread systems pthreads is emulated by Wine anyway so you'd gain nothing.
This is RedHat 9, kernel 2.4.20-31.9. It has NPTL, but we are not using it at the moment (LD_ASSUME_KERNEL=2.4.1). This does explain the problems we're having.
I have an app that is experiencing extremely slow performance (operation takes 17 seconds on native windows, over 3 minutes on Wine). One idea for solving this problem was to switch some of the synchronization operations over to native pthreads (it's using wine as part of a migration to Linux process).
Do you know for sure it's the synchro primitives that are causing the slowdown?
Pretty much. We tried writing an app that does little else, and the same ratios were kept.
The problem is that when I try to call pthread_mutex_init, pthread_mutex_lock and friends, I get quite a few deadlocks, and even when not deadlocking, it still takes over 42 seconds. When doing the same without the mutexes (I'm locking write access to a pipe - I'm not sure it's even necessary, and it is working without the lock too), wine performs at 21-26 seconds. I don't think that obtaining a posix mutex should have such harsh effect on performance.
What kind of mutex are you using?
Already said - pthread_mutex_lock and friends. Before, we were using Mutex and Event, with a call to "WaitForMultipleObjects".
Critical sections should only RPC to the wineserver (which is the slow bit) when contended, iirc ...
How can you tell whether you are in contention without RPCing? That makes no sense to me. It's also not how I read the code.
every time you block this involves a wineserver RPC so with high lock contention that could be a problem.
thanks -mike
Shachar