[cgl_discussion] Question for TEMs/ISVs/OEMs regarding pthread requirements

[Corey Minyard]

Perez-Gonzalez, Inaky wrote:

>  
>
>>scheduler activations.  It's fairly complicated to implement 
>>correctly 
>>:-).  And it fundamentally affects a lot of things, so you can't just 
>>tack it on to an existing threads package.  
>>    
>>
>
>With futexes is kind of possible to do it [I mean kind because the hard part
>is: how to identify the first locker, the one who did not go to the kernel?
>- the rest, save some small details, is not as ugly]. 
>
It's harder than you think, because the priority boosting is transitive. 
 So if process A is wanting on a mutex owned by process B, and process B 
is waiting on a mutex owned by process C, the process A will boost both 
process B and process C's priority.  And you have to do that and avoid 
infinite loops because of deadlocks.  And, even harder, you have to make 
it scalable.  And, the hardest,  for decent performance you have to be 
able to lock the mutex in userland if there's no contention, but the 
userland lock has to atomically lock the mutex and set itself as the owner.

This seems a lot easier than it really is because of all the details you 
have to handle.  Look at the locking algorithms in ssthreads, they are 
documented and you will see.

>
>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 another process 
comes along in that timeframe, it won't be able to do the priority 
boosting, and it's not like it can just wait for a little while for the 
other process to finally identify itself, that would kind of defeat the 
purpose of the whole thing :-).

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.

-Corey