[M3devel] up-front initialization of mutex/conditionvariable?

[Tony Hosking]

On 15 Dec 2009, at 10:02, Mika Nystrom wrote:

> What's the main problem you guys are trying to solve?
> 
> In my experience the biggest performance loss in moving from PM3 user
> threads to CM3 pthreads has been with programs that lock a lot but are
> actually not using the thread-safety for anything.

Exactly.  In "uniprocessor" user-threading, lock is simply INC(inCritical)/DEC(inCritical), which controls whether threads can switch or not.

> Those programs would be improved greatly by a scheme such as the one
> Tony describes, where a mutex is "passed" between the threads, with
> "real locking" only when it has to be passed from one locker to another,
> not when a single locker locks and re-locks the mutex.
> 
> But I don't see how that implies a need to change the thread-stopping
> mechanism.... it's something else, I take it?

We could use a CAS on every acquire/release, implementing the Thin Locks technique mentioned in one of the papers I cited.
I wanted to go one step more, to avoid the CAS (which has overhead beyond a simple load/store) by allowing a lock to be reserved to one thread the first time it is acquired.  That thread gets to acquire/release without CAS.  When another thread comes along and wants the lock it needs a mechanism to revoke the reservation.  That's why we need the handshake mechanism.  I could use the current signal-based approach, but that has the nasty effect of stopping the target thread in its tracks.  Better that it simply ack the revocation and then keep running.


>    Mika
> 
> hendrik at topoi.pooq.com writes:
>> On Mon, Dec 14, 2009 at 11:39:08PM -0500, Tony Hosking wrote:
>>> So, the basic scenario is as follows.  Briefly... We should ditch 
>>> signals as a mechanism for stopping threads.  The compiler should 
>>> inject a "safe-point" at each procedure call and backward branch.  At 
>>> safe-points, the thread polls a thread-local to see if the run-time 
>>> system needs it to step out-of-line for some reason.
>> 
>> ...
>> ...
>>> 
>>> The point is that uncontended locks should cost almost nothing.
>> 
>> Nothing?  All those safe-points cost time, don't they, even when no 
>> locks are being used at all?
>> 
>> Is this analogous to charging everyone for the overhead involved in 
>> recursion, even when no recursion is being used?
>> 
>> -- hendrik