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

george anzinger george at mvista.com
Mon Feb 3 13:34:17 PST 2003


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...
> 
> 
>>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




More information about the cgl_discussion mailing list