Subj : Re: RCU+SMR To : comp.programming.threads From : David Hopwood Date : Tue Jul 12 2005 12:25 am Joe Seigh wrote: > David Hopwood wrote: >> Joe Seigh wrote: >>> David Hopwood wrote: >>> >>>> I very much doubt that there is enough benefit from using lock-free >>>> techniques in *applications* to justify the complexity cost, and the >>>> effort required to learn how to use them correctly. They belong in >>>> operating systems and language implementations, where these costs are >>>> amortized over many apps. >>>> >>> Depends on the api and usage patterns that you create for the lock-free >>> stuff. >> >> I don't think it does, really. Note that I was talking about using >> lock-free techniques directly in applications; not using "infrastructure" >> libraries that happen to be implemented using lock-free stuff, but that do not >> expose it to their clients. My argument is that lock-free primitives are >> inherently too complex and error-prone to be exposed directly for general- >> purpose application programming, no matter how well-designed the API. > > My experience is that people who believe their low level api are too > complex for normal programmers to use and and only allow useage through > a high level api, generally suck at designing api's. My experience is that people generally suck at designing APIs. This does not imply that all APIs suck. > If the low level api was available, at least someone else who isn't so bad > at api design could try to design a better one. And they certainly couldn't > design a new or different api if the low level api wasn't available. That's not the case: they can always drop down to assembler. Or they can reuse the low-level guts of an open-source implementation of some other high-level API. > If the only api available is a lock-free linked list and someone wants to > design a lock-free tree, they won't be able to do one. Yes they will, by modifying the lock-free linked list code to implement a tree. "Black box" reuse doesn't work, but reuse based on modification of source code has been quite successful. If the lock-free linked list implementation doesn't come with source, throw it away; you can't rely on it. > Java is a good example here. There are a lot of classes that are final and > not extendable simply because the class author doesn't trust users to > extend their class even though that is the whole *point* of OOP. 'final' was included in Java for security reasons, because some of the system classes would have been exploitable by subclasses (it can be argued that this was addressing the symptom and not the cause of other security design problems). If an API designer is making basic mistakes in the use of 'final', they're probably making other basic mistakes, and their code would not have been reusable anyway. -- David Hopwood .