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

[Mika Nystrom]

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.

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?

    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