[cgl_discussion] Question for TEMs/ISVs/OEMs regarding pthrea d requirements

[Pradeep Kathail]

At 2/3/2003 01:34 PM -0800, george anzinger wrote:
>Perez-Gonzalez, Inaky wrote:>>It's harder than you think, because the priority boosting is
>>>transitive. 
>
>I would have said recursive :)  It is up to the user to limit the nesting of his locks.
>>
>>I know ... the thing is all this to me is simple compared to the following
>>one...[another matter is that I get it to work right]
>>
>>>>Let's say I am trapped on different sides, because I need to 
>>>
>>>have the user
>>>
>>>>level impacted as little as possible, better nothing [if I don't want
>>>>NTPLers and NGPTers to hit the roof] ...
>>>
>>>You cannot correctly implement it without changing userland.  
>>>Sorry, it just can't be done.  With the current NPTL and NGPT implementation, you end up with a window where the mutex is locked but the owner is unknown (in fact I'm not sure if the owner is ever known).  If 
>>
>>Jackpot #1 this is what is banging in my head in the last days - we have
>>been throwing out some wild ideas - last one was, heck, let's just have the
>>PID+TID beside the counter and have another, normal futex locking it all -
>>that's as little impact to the actual user space code as the A-Bomb was to
>>Nagasaki, but so far, is the only solution we can come with. We keep the
>>ball spinning
>
>Given that one can put together an atomic compare-and-swap in user space, I think one can enter an uncontested pi-mutex with just that, i.e. compare / modify + a test for success.  This assumes that one has a unique id fits in the given word size, plus one bit extra (in the kernel I used the "current" pointer and the least bit).  Exit of the area is the same overhead as entry.
>
>Now if the mutex is contested, things get rather expensive (on the order of your A-bomb) however, the task has to wait anyway...

This is correct direction for implementation. We need to avoid the cost 
of uncontested MUTEX, (probably do it in the User Space Only). For 
contested MUTEX, we can go in the kernel and cost is not an issue. 
The unlocking should be fast when no process is waiting for the MUTEX.
We can pay the cost if we have to wake up processes after unlock.

Brgds.
Pradeep


>>>Also, I don't think it's possible to do the userland-only lock on a machine that doesn't have compare-and-swap (MIPS, ARM, and old x86s don't have it, for instance).  I've spent some time thinking about it, and I don't have a solution.  It will be hard to get the kernel maintainers to take something that is not generic.
>
>I think we should think of this as instruction emulation where we go to the kernel VERY quickly (both in and out).  If we don't allow interruption, we would not need to save much context.  The major over head would be the system call instruction.
>
>But do we really need this?  I should hope that most platforms allow atomic compare-and-swap without the need for kernel protection.
>>
>>Jackpot #2 ... I don't know if Rusty's solution to this [in his futex
>>"library", __futex_down() for the i386 using "lock; decl [futex]; sete
>>[equals_zero]" is feasible or bullet proof; but at least he got it kind of
>>working, AFAIK ... never gave this one too much thinking, though - maybe it
>>is as simple as "sorry, we cannot support these machines".
>>Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
>>fault]
>
>
>
>-- 
>George Anzinger   george at mvista.com
>High-res-timers:  http://sourceforge.net/projects/high-res-timers/
>Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml