Re: pthread_mutex in a winelib dll called from a win32 application

[Mike Hearn]

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