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

Pradeep Kathail pkathail at cisco.com
Fri Jan 31 16:48:01 PST 2003

At 1/31/2003 04:57 PM -0600, Corey Minyard wrote:
>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). 

MIPS supports load/ store-conditional that can be used to implement
userland MUTEX.


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

More information about the cgl_discussion mailing list