pthread_mutex in a winelib dll called from a win32 application
Mike Hearn
mike at navi.cx
Wed Jul 21 06:50:55 CDT 2004
On Wed, 2004-07-21 at 14:40 +0300, Shachar Shemesh wrote:
> 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'm pretty sure LD_ASSUME_KERNEL doesn't work with Wine in the way it
does with most apps, but only Alexandre would know for sure.
Certainly if you have it available using NPTL is recommended.
> Pretty much. We tried writing an app that does little else, and the same
> ratios were kept.
Sounds similar to the problems TransGaming were having that prompted the
SHM wineserver.
> Already said - pthread_mutex_lock and friends.
> Before, we were using Mutex and Event, with a call to
> "WaitForMultipleObjects".
Ok, that's what I was after (what win32 mutexes) ...
> > 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.
You have a lock count that you do an InterlockedIncrement/Decrement on,
so if nothing was holding the lock you just sail right through it. If
something already changed the lock count then you block on a wait fd
provided by the wineserver:
if (interlocked_inc( &crit->LockCount ))
{
if (crit->OwningThread == (HANDLE)GetCurrentThreadId())
{
crit->RecursionCount++;
return STATUS_SUCCESS;
}
/* Now wait for it */
RtlpWaitForCriticalSection( crit );
}
Obviously this is only the case for these kind of locks.
WaitForSingleObject will usually RPC.
thanks -mike
More information about the wine-devel
mailing list