Which are really anonymous?

Which can be used with facebook, myspace etc, in other words: are fresh ?

Which can you recommend?

Thanks for your help,
Dschibut

P.S.: In my land, the freedom of speech is somehow constrained, please give me a hint, if you are not sure about your recommendation.

I can only think of one situation where it’d be usefull- with hash tables, when you have to grow or shrink the entire hashtable. While populating the new hashtable, you can still allow read-only access to the old hashtable. Only at the end, when you want to update the pointers to point to the new hashtable, do you need an exclusive write lock. But even here it’s wrong to use, as the common case is that you’re not resizing the table on an insert or remove. If fact, you almost never are- only 1 time in N or less (where N is the number of elements in the table) are you resizing the table, otherwise hashtables don’t have O(1) amoritized insert/remove cost. In the common case you just want to go straight for the write lock, as the read-only phase will be almost nil. So what use is upgradeable, again?

The next thing is that my opinion of C++ is born of actually having programmed in it professionally. Also note that I’m not that much of an elitist when it comes to languages. While I prefer Ocaml and Haskell as languages, I still very much like C, and have been known to voluntarily program in PHP, Perl, and Visual Basic. Heck, I’ve even been known to argue that for certain jobs, Perl or Visual Basic are better tools than Ocaml! So this isn’t just lisp-style snobbery. The intense dislike I bear against C++ is earned.

To assume mass-stupidity from a group of internationally recognized experts of a field, any field, appears to me to be less than a bright thing to do. Yes, groups of experts do make mistakes. It happens more often than I’d like. But I’ll take those results over groups of non-experts any day.

And fwiw, I’ve been monitoring the technical conversation regarding the C++ memory model (Hans Boehm among the active participants) over the past several months. Trust me, these guys know what they’re doing. Publicly ridicule them at the risk of your own reputation.

If that group of so-called experts consistently display poor judgement and lack of fundamental knowledge, then it’s a pretty safe bet that they will continue to do so. And the fact that there was a smattering of smart people involved doesn’t matter- as generally the smart people get shouted down by the idiots. Hans Boehm is a pretty smart guy. So is Colin Powell.

Given the shock people had when Hans showed the reordering problem, I have to conclude that the C++ committee knows as much about the reality of multithreaded programming as the neocons do of the middle east. Now, I suppose it’s possible that this report of the goings on at the meeting are completely false to fact. I wasn’t there, but I haven’t heard of anyone claiming this. But if it is even roughly or approximately true, I’m pretty safe with this opinion.

For example- looking at the spec you posted, I notice one glaring thing. They’re using templates to express an is-a relationship. This strikes me as being a classic, gold-standard example of what normal object inheritance. And yet, they use templates. One wonders why. The only reason I can come up with is that templates are “cool”, and that the same proposal, except using object inheritance instead of templates, would have a much reduced chance of passing muster with the standards committee for stylistic reasons. “This is C++, not Java!” Either that, or the people writting the standard don’t understand object orieted design (this isn’t the first time this has happened with C++, witness iostreams).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html

Because I’m writing into a category titled “Why C++ Sucks” I have reservations that anyone will take the time. However I wanted to at least put to rest the notion that the C++ committee is unaware of the problems concerned with upgrading two read locks.

The paper at the url above proposes 3 types of mutexes (and associated locks): sharable, upgradable and exclusive. Call these read, upgradable and write if you wish, I’m not married to the names. There is no blocking upgrade path from sharable to exclusive. One can only upgrade from an upgradable to an exclusive. And though an upgradable mutex can share ownership with multiple sharables, it can not share with any other upgradable. Therefore there can be only one mutex at a time that is trying to upgrade to exclusive.

Avoiding the deadlock discussed in this blog is the entire reason the upgradable mutex exists in the proposal.

Admittedly there is a 2-word type-o / think-o in the proposal under the definition of unlock_upgradable_and_lock(). My bad. It has been noted and will be corrected should these words approach a technical report or a standard.

> Never mind the niggling little implementation details. …Of course, the > only nit they could find to pick was with his spelling.

Or perhaps it was because the people I presented to had the benefit of the presentation, explaining many details. And this audience was also aware of the years of research, plus actual working implementation behind the proposal.

To assume mass-stupidity from a group of internationally recognized experts of a field, any field, appears to me to be less than a bright thing to do. Yes, groups of experts do make mistakes. It happens more often than I’d like. But I’ll take those results over groups of non-experts any day.

And fwiw, I’ve been monitoring the technical conversation regarding the C++ memory model (Hans Boehm among the active participants) over the past several months. Trust me, these guys know what they’re doing. Publicly ridicule them at the risk of your own reputation.