8 ms·
The documentation is viewed via an embedded frame. So you can't save URLs to the documentation. This is a known bad practice for web sites. The API changes w
by adekok 10y ago
The documentation is viewed via an embedded frame. So you can't save URLs to the documentation. This is a known bad practice for web sites.
The API changes with every release. WTF?
struct lfds710_freelist_element;
Really? Just... really? In order to use a newer version this library, you have to change your entire application for the updated function names.
And many of the lock-free structures are add-only. The binary tree is unbalanced. Which makes it not a very good binary tree.
This looks like it was written by somone who heard "lock free", and went "cool, I'll write a library!"
And he missed the last 40 years of software best practices.
The web site is bad, the APIs are bad, the functions aren't very useful, the library isn't very portable, etc.
People shouldn't use this library for anything.
[edit] Updated the comment about "someone" being a 16 year-old student.
- huhtenberg 10y agoWho peed in your espresso this morning?
- adekok 10y agoThe best response to a technical review of software is an ad hominem. Good to know.
- deleted 10y ago[deleted]
- DiabloD3 10y agoWell, what we should be doing is a double blind test to find out if pee in espresso improves performance, and what the minimum effective dose is.
- ma2rten 10y agoWell, ... your technical review was ad hominem in the first place.
- adekok 10y agoBecause saying someone looks 16 is an insult?
- loeg 10y agoWhen you say it like you did initially, yes!
- arcticbull 10y agoI think that's actually the definition of an ad hominem attack :)
- deleted 10y ago[deleted]
- nothrabannosir 10y ago> This looks like it was written by a 16 year-old student who heard "lock free", and went "cool, I'll write a library!" Nothing wrong with that, though. In fact, that's great. Word to the 16-year-olds (or any-year-olds) doing that: put a disclaimer in your README to avoid this kind of reply being top comment in a HN thread about your work :)
- adekok 10y agoI wrote code when I was 16. There's nothing wrong with being that age. What is wrong is not learning from others. This library follows many practices which are well known as "worst practices" in the industry.
- partycoder 10y agoCan you elaborate more on those "worst practices"?
- erichdongubler 10y agoUh...what about typedef? typedef lfds710_freelist_element freelist_element;
- adekok 10y agoSure. Did he include the typedefs in his code? Not that I can see (on a quick scan). So the only way to use his library is to create your own wrapper functions. And update them every time he updates his library. Thanks, but no thanks.
- liblfds 10y agoCould you explain why this is the only way to use the library? why are typedefs essential for use?
- cyphar 10y agoHaving version numbers in struct and function names is what he's saying is a bad idea. Typedefs would be a way to achieve it, but you have to write a wrapper library to do that. Why not just use symbol versioning like glibc does.
- liblfds 10y agoYou have to remember what I'm looking to achive here is that a new version can be released, and used, while the existing codebase using the old versions is utterly unchanged. The APIs are unchanged, the library they link to is unchanged - totally, utterly, unchanged, not one single byte of difference. I've not thought about (or really come across - I think I have seen it on Windows) symbol versioning, but from what I've understood (from a pretty terrible explanation online) it would mean the library ends up with a single library file, which gains new members as new releases of the library occur. This still has the problem of imposing unvalidated change on the user - the library changes under him. What if I introduced new bugs?
- 10y ago
- jhpriestley 10y agoThe criticism of the documentation is fair, but it's an incredibly trivial point. You can save URLs to the documentation if you right-click the link. For example, here is the link to the rationale for the versioned naming scheme: http://liblfds.org/mediawiki/index.php?title=Introduction#Concurrent_Use_of_Multiple_Versions http://liblfds.org/mediawiki/index.php?title=Introduction#Co... Do you even understand the significance of "lock-free" in the title here? Do you have some basis to think that the weaknesses of the data structures, like unbalanced trees and add-only collections, can be remedied without using locks? If you do then that would be an interesting criticism, but as it is it looks like you just opened the page, looked around for a few things to criticize, and then wrote this sour, shallow, dismissive comment.
- openasocket 10y agoA quick google shows that there are lock-free implementations of AVL trees and red-black trees. And every paper I've ever read about lock-free data structures includes both addition and removal operations.
- liblfds 10y agoYes. I have seen the white paper for the red-black tree, and the approach used should work for AVL (I've not seen that paper). I've just not had time to implement yet. A full O(log n) data structure is necessary for the library to be really useful piece of work - but there's a lot of other things which are necessary for that, too, and they have so far taken up most of the development time. About 10% of the effort so far has gone into coding the actual data structures - almost all the work goes into testing, benchmarking, performance tuning, documentation, porting to new platforms, fundamental improvements in the basic design and so on. The benchmark app alone has taken all in all about six full months to write. I thought it'd be simple, it turned out to be a tar-pit!
- openasocket 10y agoHonestly, I wouldn't bother with red-black or AVL. I'm not sure about the current state of lock-free data structures, but I prefer a B-Tree to a red-black or AVL tree. At least in the single-threaded case B-Tree operations tend to be faster, have better cache locality, etc. Google reveals there are lock-free implementations of B-Trees, so maybe look into those instead?
- jotux 10y agoComments like this are exactly why people are afraid to release projects to the public and contribute to open source.
- adekok 10y agoIf you're afraid of negative feedback, you will never do anything, and you will never learn anything. In this case, I'm astonished at just how many bad practices the author has engaged in. Do most software projects have structs / functions / whatever where the names are versioned? It's one thing for TempleOS to invent his own OS, build system, programming language, GUI, etc. He made some odd choices, but at least he's clear he doesn't care (much) about other people using his code. And, it's clear his code works, and does something useful. The author of this library has invented many of his own programming practices... which are clearly worse than current industry practices. Why? I can't say. But I can say that they are worse. I just don't understand this attitude that all feedback has to be couched carefully to avoid hurting anyones feelings. If it's bad, it's bad. Perhaps you could be productive, and post your review of his code. If it's in any way negative, (by your standards), I should jump on the review as being overly negative, and "you're the reason why people don't do open source." Adults should be able to take criticism. If they can't, I have very little sympathy for them.
- jotux 10y ago>I just don't understand this attitude that all feedback has to be couched carefully to avoid hurting anyones feelings. >Adults should be able to take criticism. If they can't, I have very little sympathy for them. Again, your outlook is toxic to newcomers. Yes people should be able to handle criticism but you should be capable of crafting that criticism in a way that isn't mean spirited and rude. I wish more projects and communities had code of conduct rules similar to the rust language: https://www.rust-lang.org/conduct.html https://www.rust-lang.org/conduct.html Which includes rules your comment would obviously violate: Please be kind and courteous. There’s no need to be mean or rude.
- cyphar 10y ago
- nneonneo 10y agoThe library also uses some absurdly long identifiers which are bound to clutter your code one way or another. To iterate a binary tree, use while(lfds710_btree_au_get_by_absolute_position_and_then_by_relative_position(state, &element, LFDS710_BTREE_AU_SMALLEST_IN_TREE, LFDS710_BTREE_AU_INORDER_WALK_FROM_SMALLEST_TO_LARGEST)) It's not going to be possible to remember what names to use when you need to iterate. Or, take the initialization routine. You first call lfds710_btree_au_init_valid_on_current_logical_core( &state, key_compare_function, LFDS710_BTREE_AU_EXISTING_KEY_FAIL, NULL ); on one core, which is perhaps reasonable, but then you call LFDS710_MISC_MAKE_VALID_ON_CURRENT_LOGICAL_CORE_INITS_COMPLETED_BEFORE_NOW_ON_ANY_OTHER_LOGICAL_CORE() on other cores. That is one hell of a #define, and it's not even clear from the name what it's doing. It seems like "LFDS710_MISC_SYNC_INITS" or something along those lines would be clearer and easier to remember.
- liblfds 10y agoYes, some of the identifiers are very long. The aim was to make the APIs self-explanatory. It should be possible to read an API and know what it does. It's challanging to explain an inorder walk, and its direction, in a shorter form. The goal of course is for all identifiers to be as short as possible.
- Sir_Cmpwn 10y agoHoly shit! That's 71 characters, which leaves you 9 characters for your code. 4 of that goes to indentation, 3 of that goes to (); and you have 2 characters left for the parameters before you break the 80 character limit. That's horrifying.
- liblfds 10y ago> The documentation is viewed via an embedded frame. So you > can't save URLs to the documentation. This is a known bad > practice for web sites. Yes and no. The site currently is arranged with a set of tabs on the left and a frame on the right. It had to be a frame because some of the web-based apps, such as the mediawiki used for documentation, generate output encapsulated in the "<HTML>" tag. As such, their output cannot be captured and placed into a div; it has to go into its own frame. However, the documentation can be opened in a new tab (right click, open in new tab) and then where it has its own browser window, the URL is displayed as normal. Of course, this is not the default behaviour - the user has to do something to get it, and to realise that it is possible. That is a problem. The only obvious solution is to have the documentation automatically open in a new window. That's a bit unpleasent though - new windows popping up unexpectedly is not good for the user experience. > The API changes with every release. WTF? Really? Just... really? In order to use a newer version this library, you have to change your entire application for the updated function names. No. All versions of the library can concurrently be included and linked against. The reason for this is so that any code which using an existing version of the library does not have to be modified at all - and so does not need to be revalidated - when a new version is published. IME, once code is written, and given that it works, it tends quite strongly not to change. It works, so why spend time and effort merely to change it? however, if a new version of a library comes out, anything could have happened - so existing code has to be revalidated. It's extra work. This is avoided by supporting concurrent use of multiple library versions. > And many of the lock-free structures are add-only. The binary tree is unbalanced. Which makes it not a very > good binary tree. The add-onlys were thrown together in a week or so many months ago, just to get those classes of data strutures out there, as writing the full versions of them will take some time. There is in fact for eaxmple a full, balanced binary tree, in the literature. That's on the list! Regarding being unbalanced, one way to address this is to hash the key before inserting a new node. > This looks like it was written by somone who heard "lock free", and went "cool, I'll write a library!" That's a bit unfair. The library is eight years old now. It's not a flash in the pan. > The web site is bad, the APIs are bad, the functions aren't very useful, the library isn't very portable, > etc. It's actually as portable as it is possible for a lock-free library to be. Only a fairly few platforms provide atomic instrinsics. As far as GCC provides support, they are all suppoted, and I believe GCC supports all of them.