|
|
Subscribe / Log in / New account

what's needed is a application barrier() call

what's needed is a application barrier() call

Posted Sep 10, 2009 1:43 UTC (Thu) by ras (subscriber, #33059)
In reply to: what's needed is a application barrier() call by vaurora
Parent article: POSIX v. reality: A position on O_PONIES

The problem can be stated simply enough. User land application writers need to be able to do atomic updates, and (orthogonally) for way for information to be sure on disk single way that works across all file systems without special libraries or having to change their code. That means those interfaces must be in POSIX, and with the added complication that all existing file systems we have, and all those we can envisage in the future can implement them efficiently.

Maybe write barriers are just the interface we need, maybe not. What we need is a Paul McKenney to do for this problem what Paul did for a very similar problem in multi CPU memory architectures. He wrote the RCU stuff and in the process became intimately familiar for the problem and all possible solutions. He then worked for years to get a standard set of functions that solved the problem to be added to the C standard library. Where is your white knight in shining armour when you need them? Who knows, maybe our knight will be female for a change.

One thing hasn't changed though, and that is the ability of the female of our special to create work. Now I feel compelled to learn about Featherstich.


to post comments

what's needed is a application barrier() call

Posted Sep 10, 2009 11:18 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

He then worked for years to get a standard set of functions that solved the problem to be added to the C standard library.
Obviously I missed something, but userspace RCU isn't in glibc and certainly isn't in POSIX.

what's needed is a application barrier() call

Posted Sep 10, 2009 12:19 UTC (Thu) by ras (subscriber, #33059) [Link] (1 responses)

> Obviously I missed something, but userspace RCU isn't in glibc
> and certainly isn't in POSIX.

Paul describes his efforts so far here: http://www.rdrop.com/users/paulmck/scalability/paper/CPP-...

what's needed is a application barrier() call

Posted Sep 10, 2009 13:37 UTC (Thu) by nix (subscriber, #2304) [Link]

Ah, thanks, great stuff. I didn't realise the 'threads cannot be implemented in a library' standardization fix had got as far as this. I'd encountered bits of this (quick_exit()), but not realised why they were useful.

(And Paul's slides are the best explanation of the problem I've ever seen. Slide 26 is particularly good ;} )

what's needed is a application barrier() call

Posted Sep 10, 2009 11:19 UTC (Thu) by nix (subscriber, #2304) [Link]

btw, even I found your female crack to be cringeworthy, and I'm male. Less of the stupid sexist jokes, please.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds