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

Perez-Gonzalez, Inaky inaky.perez-gonzalez at intel.com
Mon Feb 3 11:18:44 PST 2003

> It's harder than you think, because the priority boosting is 
> transitive. 

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 sollution we can come with. We keep the
ball spinning

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

Jackpot #2 ... I don't know if Rusty's sollution 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

More information about the cgl_discussion mailing list