| jeffr_tech ( |
Re: RCU
So we can't use it until the patent expires. Neither can anyone other than Linux and IBM, I believe. Or was it SGI?
Anyway, we've come up with alternate ways to get the same concurrency. We have 'rmlock' which are read-mostly locks in the tree. They allow you to read without a lock, essentially like RCU, but use a different method to synchronize updates to avoid the patent. Our update is slightly more expensive but hopefully for both systems very infrequent.
We've also been looking at lock free or entirely atomic based datastructures and have used them effectively in a few places where RCU would've been nice. I don't think we're terribly hindered by not having RCU at the moment. Of course we're working on scalability to 16-32 processors at the moment and not many dozens or hundreds. In many cases we did extremely coarse locking early on and now that we're coming back around we're doing locking that should scale to much larger machines than we have access to presently.
So we can't use it until the patent expires. Neither can anyone other than Linux and IBM, I believe. Or was it SGI?
Anyway, we've come up with alternate ways to get the same concurrency. We have 'rmlock' which are read-mostly locks in the tree. They allow you to read without a lock, essentially like RCU, but use a different method to synchronize updates to avoid the patent. Our update is slightly more expensive but hopefully for both systems very infrequent.
We've also been looking at lock free or entirely atomic based datastructures and have used them effectively in a few places where RCU would've been nice. I don't think we're terribly hindered by not having RCU at the moment. Of course we're working on scalability to 16-32 processors at the moment and not many dozens or hundreds. In many cases we did extremely coarse locking early on and now that we're coming back around we're doing locking that should scale to much larger machines than we have access to presently.